MeitY CCTV Essential Requirements, Clause by Clause (Plain English)
MeitY's "Essential Requirement(s) for Security of CCTV" are 30 tested clauses covering hardware, firmware, secure process and product development, in Gazette S.O. 1119(E) of 6 March 2024 (procurement) and S.O. 1652(E) of 9 April 2024 (compulsory registration). Signed firmware, secure boot, anti-rollback, an SBOM and a hard-coded-credential review are in. A standalone "no default password" clause is not.
Verified against
- MeitY (IPHW Division), Gazette notification S.O. 1119(E), 6 March 2024, Appendix 'A' "Essential Requirement(s) for Security of CCTV", pages 32–43 (egazette PDF).
- MeitY (IPHW Division), Gazette order S.O. 1652(E), 9 April 2024, amending the Compulsory Registration Order (CRO) for "CCTV Camera" at S. No. 41, Annexure "Essential Requirement(s) for Security of CCTV", pages 14–24 (egazette PDF). Same clauses in substance, numbered differently from 2.7 on.
- STQC, IoTSCS P01, "Procedure for CCTV Testing Evaluation and Certification", Issue 01, 21-05-2024, Annexure A (STQC PDF). Its clause table follows the S.O. 1119(E) numbering.
- STQC IoTSCS page, which says the ERs "under CRO and Public Procurement (Preference to Make in India) Order (PPP-MII) are same", citing MeitY circular W-18/26/2025-IPHW of 04.02.2026 (STQC).
- BIS Registration Department, "Guidelines for implementation of Essential Requirement(s) for Security of CCTV", 22 Oct 2024, with MeitY's Series Guidelines (crsbis.in PDF).
- Checked 13 Oct 2026.
The 30 clauses, in plain English
"Verify" means the testing lab checks it, often "in presence of OEM team". Numbers and page links follow S.O. 1119(E); CRO numbers, where different, are in brackets.
| # | What it requires, in plain English | Ask the vendor | Source |
|---|---|---|---|
| 1.1 | USB, UART and other serial debug ports are disabled, or locked by a complex password | Which debug ports does the production unit expose? | p.32–33 |
| 1.2 | Every camera has its own keys and certificates, not one shared set | Are TLS keys unique per unit? | p.33 |
| 1.3 | Chip-level debug (JTAG, SWD) is disabled or protected | Is JTAG fused off in production? | p.33–34 |
| 1.4 | If the chip has a TEE, secure element or TPM, it must be used. Having one and not enabling it is a non-conformance | Does the SoC have a TEE/TPM, and is it on? | p.34 |
| 1.5 | Private keys, certificates and sensitive data sit in secure hardware or under strong encryption | Where are the camera's keys and passwords stored? | p.34–35 |
| 1.6 | Tamper resistance and/or tamper detection, tested as measures against software and hardware tampering | What stops someone altering the firmware or the board? | p.35 |
| 1.7 | Chip-maker IP-protection features are switched on, or a declaration that none exist | Declaration copy, please | p.35 |
| 1.8 | Secure boot: a valid signed image boots; a tampered or unsigned one must not | Secure boot on by default? | p.35 |
| 1.9 | Random numbers come from a cryptographically secure generator | (lab item; no buyer action) | p.35–36 |
| 2.1 | Memory protection (ASLR, DEP) enabled where the OS supports it | (lab item) | p.36 |
| 2.2 | Data in transit protected by TLS; lab checks ciphers, open ports (Nmap) and man-in-the-middle resistance | Which TLS versions? Can HTTP and Telnet be turned off? | p.36 |
| 2.3 | Firmware validates server certificates, including chain and revocation | Which servers does the camera call home to? | p.36–37 |
| 2.4 | Banned C functions replaced by safe ones; licensed static-analysis review | (lab item) | p.37 |
| 2.5 | Each firmware has a software bill of materials with versions and published vulnerabilities; vendor must have a process to patch them and inform customers | How will you tell us about a vulnerability? | p.38 |
| 2.6 | All code, including third-party libraries, reviewed for hard-coded credentials (backdoors) | Written statement: no hard-coded accounts | p.38–39 |
| 2.7 | Firmware pins the signature of trusted server(s) | Same as 2.3 | p.39 |
| 2.8 (CRO 2.7) | Controls that hinder firmware reverse engineering (e.g. debug symbols removed) | (lab item) | p.39 |
| 2.9 (CRO 2.8) | Update process resists time-of-check/time-of-use attacks | (lab item) | p.39–40 |
| 2.10 (CRO 2.9) | Signed firmware updates: a tampered update package must be rejected | Are your downloads signed? | p.40 |
| 2.11 (CRO 2.10) | Anti-rollback: the camera cannot be downgraded to older valid firmware | See "What breaks", below | p.40 |
| 2.12 (CRO 2.11) | Updates on a schedule; vendor submits an SOP for automatic or manual updates | Can auto-update be disabled? | p.40–41 |
| 3.1 | Wireless links mutually authenticated (or a declaration of no wireless) | Wi-Fi present? | p.41 |
| 3.2 | Wireless traffic encrypted | Same | p.41 |
| 3.3 | Trusted supply chain: a managed bill of materials for security-critical hardware such as the SoC | Which SoC, from where? | p.41 |
| 3.4 | Supply-chain risk assessment, continuity plans and post-incident summaries submitted | (lab item) | p.41–42 |
| 3.5 | No proprietary network protocols, or full implementation details and source code given to the lab | Does the camera use any private protocol besides RTSP/ONVIF? | p.42 |
| 4.1 | Design details down to PCBA and SoC level, for counterfeit and malware checks | (lab item) | p.42 |
| 4.2 | Counterfeit and tainted-product mitigation built into development | (lab item) | p.42 |
| 4.3 | Up-to-date malware scanning in code acceptance and before packaging | (lab item) | p.42–43 |
| 4.4 | Supply-chain risk assessment (same wording as 3.4) | — | p.43 |
Above the table, Appendix A lists five "brief requirements": tamper-resistant enclosures, role-based access control, encrypted transmission, "Regular Updates, Disable Unused Features and Strong Password Policies", and penetration testing (p.32). Blogs quote this preamble; the lab tests the 30 clauses.
Where the documents differ
- No standalone default-password clause. Passwords appear in the preamble ("Strong Password Policies"), in 1.1 (debug ports) and in 2.6 (hard-coded credentials). A camera shipped with a blank or shared admin password is not addressed by a numbered clause. Put it in your PO yourself.
- No public vulnerability-disclosure programme. Clause 2.5 asks for a process to patch and to inform customers. It does not require a bug bounty, a public advisory page or a fixed patch time.
- Component origin is disclosed to labs, not banned. Clause 3.3 asks for "trusted sources" via a managed BoM; no country is named. Separately, MeitY's Series Guidelines say the certificate must show chipset make, model and country of origin, firmware version and hash (BIS PDF, item 7).
- Clause numbers differ between the two Gazettes. The CRO annexure uses "2.7" twice, so its later 2.7–2.11 are 1119's 2.8–2.12 (S.O. 1652(E), pp.21–22). STQC's P01 follows 1119; STQC now issues the security test report "as per the Essential Requirements (ERs) under CRO".
- Cameras only. S.O. 1119(E) says "security norms for the DVR and NVR will be notified subsequently" (para 5), and the CRO entry is for "CCTV Camera". See do NVRs and DVRs need STQC/BIS certification.
- Loose ends. Clause 2.12 points to "C20, C21 and C22" security requirements that the Appendix never defines, and 4.4 repeats 3.4. The P01 procedure also calls the 6 March notice a "Gadget Notification dated 6 Match". When you cite a clause in a PO or tender, quote its wording and name the Gazette, not just the number.
- Two orders, one list. The same ERs serve sale (CRO) and tenders (procurement order), per STQC; our STQC ER vs BIS CRS, CRO vs PPO explainer untangles the routes.
What breaks in a factory
- Anti-rollback (2.11) plus a firmware-specific certificate. MeitY's Series Guidelines treat each firmware version, by hash, as a separate series (item 4), and the certificate names the firmware version and hash. Under 2.11 the camera cannot be downgraded, so if an update breaks the link with your older NVR or VMS, you may not be able to go back. Test one camera on a spare port first.
- Auto-update (2.12) on an isolated camera VLAN. Cameras on a PoE subnet with no internet won't fetch updates. Agree who flashes firmware, and how, before handover.
- Power cuts mid-update. The ER tests signed updates, not power loss. Ask what happens if supply drops mid-flash; update only on UPS.
- Proprietary protocols (3.5). The ER lets a vendor keep a private protocol if it discloses it to the lab. It does not require ONVIF or open RTSP. Write those into your tender specification separately.
- Tamper detection (1.6) is about software and hardware tampering with the device. It does not cover dust on the dome or a camera knocked off-aim by a forklift.
When to call the installer / what to ask the vendor
Before the PO, ask for: the ER test report for the exact model; the firmware version and hash it covers; SoC make and origin; the 2.5 vulnerability-notification route; and a written statement on default and hard-coded accounts. Check the model in our CCTV certificate checker.
Once the cameras pass, the next question is what they show. Mama reads existing cameras over RTSP/ONVIF and tells the owner where machines sat idle yesterday. Leave an email or phone in the form below.
FAQ
Do NVRs and DVRs have to meet the CCTV Essential Requirements? Not under this Appendix. The 6 March 2024 Gazette says security norms for DVRs and NVRs "will be notified subsequently". CCTV recorders are still under BIS compulsory registration for safety (IS 13252 Part 1), per BIS's guidelines.
How long is an STQC ER test report valid? Three years from issue, per para 5 of S.O. 1119(E). STQC's P01 says its certificate is valid three years "subjected to surveillance audit".
Do the Essential Requirements ban Chinese chips? No clause names a country. Clause 3.3 requires a trusted supply chain and a managed BoM for security-critical parts such as the SoC, and the certificate must state the chipset's country of origin.