रजिस्ट्री सं. डी.एल.- 33004/99 REGD. No. D. L.

-33004/99

सी.जी.-डी.एल.-अ.-09042024-253632
xxxGIDHxxx
CG-DL-E-09042024-253632
xxxGIDExxx
असाधारण
EXTRAORDINARY
भाग II—खण्ड 3—उप-खण्ड (ii)
PART II—Section 3—Sub-section (ii)
प्राजधकार से प्रकाजित
PUBLISHED BY AUTHORITY

सं. 1569] िई दद्ली, मंगलिार, अप्रैल 9, 2024/चैत्र 20, 1946

No. 1569] NEW DELHI, TUESDAY, APRIL 9, 2024/CHAITRA 20, 1946

MINISTRY OF ELECTRONICS AND INFORMATION TECHNOLOGY

(IPHW Division)
ORDER

New Delhi, the 9th April, 2024

Subject: Amendment to the “Electronics and Information Technology Goods (Requirement of Compulsory
Registration) Order, 2021”
S.O. 1652(E).—In exercise of the powers conferred by sub-section (1) and (2) of section 16 read with sub
section (3) of section 25 of the Bureau of Indian Standards Act, 2016, (11 of 2016), the Central Government is of the
opinion that it is necessary or expedient so to do in the public interest, hereby makes the following amendments to the
“Electronics and Information Technology Goods (Requirements for Compulsory Registration) Order, 2021”:
2. For CCTV Camera, the following entry of Column (5) be added at S. No. 41 in the Schedule of the
“Electronics and Information Technology Goods (Requirements for Compulsory Registration) Order, 2021.

Sr. No. Goods or Articles Indian Standard Title of Indian Standard Essential
(1) (2) (3) (4) Requirement(s)
(5)
41 CCTV Camera IS 13252: Part 1: 2010 Information Technology Essential
Equipment - Safety General Requirement(s) for
Requirements-- CCTV as per Annexure

3. The provisions of “Electronics and Information Technology Goods (Requirements for Compulsory
Registration) Order, 2021” shall apply on the Goods or articles as specified in the column (2) added to the schedule of
the said Order by virtue of this notification, for conforming to the corresponding Essential Requirement(s) as specified
in the column (5), on the expiry of six months from the date of publication of this notification in the Official Gazette.
As per Scheme II of BIS Conformity Assessment Regulations, 2018, submission of test reports from BIS recognized
labs, shall form a pre -requisite for obtaining license to use Standard Mark.
[F.No. W-43/11/2021-IPHW]
ASHA NANGIA, Group Coordinator & Scientist 'G'

2475 GI/2024 (1)

2 THE GAZETTE OF INDIA : EXTRAORDINARY [PART II—SEC. 3(ii)]

Annexure
Essential Requirement(s) for Security of CCTV
Securing a CCTV (Closed-Circuit Television) system is crucial to protect sensitive information and ensure
the system operates effectively. Key areas of testing include exposed network services, device communication
protocols, physical access to the device’s UART, JTAG, SWD, etc., the ability to extract memory and firmware,
firmware update process security and storage and encryption of data. Here are brief requirements for the security of a
CCTV system:
1. Physical Security - Use tamper-resistant camera enclosures and locking mechanisms to deter physical
tampering.
2. Access Control by Authentication, Role-Based Access Control (RBAC) and regularly review and update
access permissions to reflect personnel changes.
3. Network Security by employing encryption of data transmission
4. Software Security by Regular Updates, Disable Unused Features and Strong Password Policies
5. Penetration Testing: Employ penetration testing to assess the system's resistance to cyberattacks and address
vulnerabilities.
Essential Security Requirements

Sr. No. Category Testing What to be tested Documents Required

Parameter
1. Hardware Level 1.1 Verify that 1. Identification of the The vendor shall provide the
Security Parameter application layer availability of debugging following:
(supported by debugging interfaces such as USB, a. Datasheet of the SoC
software) interfaces such UART, and other serial being used in the device.
USB, UART, and variants b. Documentation related to
other serial through the Datasheet of ports/interfaces enabled in
variants are the SoC being used in the the production devices and
disabled or device under test the related access control
protected by a 2. Verification and mechanism for protection of
complex validation of the the same.
password. ports/interfaces enabled in c. Process flow of the
the production devices Manufacturing/Provisioning
and the related access of the device
control mechanism for
protection of the same as
declared in the vendor
documentation
3. Testing, in presence of
OEM team, to verify the
enabling/disabling of all
the ports and debugging
interfaces such as USB,
UART, and other serial
variants using their
relevant hardware-based
debuggers and access
control mechanisms in
case the interface is
enabled.
4. Process verification of
the manufacturing facility
to validate the vendor's
claim regarding the
debugging interfaces
which are closed/disabled
during provisioning.
[For instance, through
Block connection diagram
depicting pin connections
between the host
[भाग II—खण्ड 3(ii)] भारत का रािपत्र : असाधारण 3
microcontroller and its
interactions with various
sub
components/peripherals.]
1.2 Verify that Identifying all the keys Vendor shall submit the
cryptographic and certificates being following:
keys and used in the device eco- 1. List of all keys and
certificates are system and verification certificates being used in the
unique to each through: device ecosystem
individual device. • Testing, in 2. Key management life
presence of cycle (purpose, generation,
OEM team storage,
• Code review destruction/zeroization,
• Process audit of validity, key
the key-life cycle changeover/rotation)
process
1.3 Verify that 1. Identification of the The vendor shall provide the
on-chip availability of debugging following:
debugging interfaces such as USB, a. Datasheet of the SoC
interfaces such as UART, and other serial being used in the device.
JTAG or SWD variants b. Documentation related to
are disabled or through the Datasheet of ports/interfaces enabled in
that available the SoC being used in the the production devices and
protection device under test the related access control
mechanism is 2. Verification and mechanism for protection of
enabled and validation of the the same.
configured ports/interfaces enabled in c. Process flow of the
appropriately. the production devices Manufacturing/Provisioning
and the related access of the device
control mechanism for
protection of the same as
declared in the vendor
documentation
3. Testing, in presence of
OEM team, to verify the
enabling/disabling of all
the ports and debugging
interfaces such as USB,
UART, and other serial
variants using their
relevant hardware based
debuggers and access
control mechanisms in
case the interface is
enabled.
4. Process audit of the
manufacturing facility to
validate the vendor's
claim regarding the
debugging interfaces
which are closed/disabled
during provisioning.
[For instance, through
Block connection diagram
depicting pin connections
between the host
microcontroller and its
interactions with various
sub
components/peripherals.]
4 THE GAZETTE OF INDIA : EXTRAORDINARY [PART II—SEC. 3(ii)]

1.4 Verify that Identifying whether The vendor shall provide the
trusted execution TEE/SE/TPM is available following:
is implemented or not in the device 1. Datasheet of the SoC
and enabled, if through the SoC datasheet being used in the device.
available on the and technical
device SoC or documentation submitted 2. User manual/ Technical
CPU. by the vendor. specifications of the device
Further assessment is
done on the basis of 3. Code snippets of the TEE
scenarios as applicable to API call, wherever
device as defined below: applicable
CASE 1: TEE/SE/TPM
is not available:
No further assessment
CASE 2: TEE/SE/TPM
is available and enabled:
Verification through
code-review that crypto
functions are called
through TEE/SE/TPM
APIs.
CASE 3: TEE/SE/TPM
is available but not
enabled by the vendor:
Termed as non-
conformance to the
requirement. OEM is
required to enable and
implement the
TEE/SE/TPM.
1.5 Verify that Identifying all the keys Vendor shall submit the
sensitive data, and certificates being following:
private keys and used in the device eco- 1. List of all keys and
certificates are system, sensitive data and certificates being used in the
stored securely in their storage device ecosystem
a Secure Element, mechanism(s); and 2. List of all the sensitive
TPM, TEE verification through: data with their intended
(Trusted • Testing, in usage and secure storage
Execution presence of mechanism(s) as
Environment), or OEM team implemented along with
protected using • Code review secure configurations to be
strong enabled in the device.
• Process audit of
cryptography. 3. Key management life
the key-life cycle
process cycle (purpose, generation,
storage,
destruction/zeroization,
validity, key
changeover/rotation) private
keys and certificates.
1.6Verify the Testing, in presence of Vendor shall submit the
presence of OEM team, to verify the following:
tamper resistance measures implemented in 1. Measures available in the
and/or tamper the device to prevent device to prevent software
detection software and hardware tampering.
features. tampering. 2. Measures available in the
device to prevent hardware
tampering.
1.7 Verify that Testing, in presence of Vendor shall submit the
any available OEM team, to verify the following:
Intellectual enabling of the 1. Datasheet of the SoC
[भाग II—खण्ड 3(ii)] भारत का रािपत्र : असाधारण 5
Property Intellectual Property 2. Documentation regarding
protection protection technologies the Intellectual Property
technologies provided by the chip protection technologies
provided by the manufacturer, if available. provided by the chip

chip manufacturer manufacturer which have

are enabled. been enabled.
3. In case, no Intellectual
Property protection
technologies are being
provided by the chip
manufacturer, then a
declaration stating the same.
1.8 Verify the Testing, in presence of Vendor shall submit the
device validates OEM team, to verify the following:
the boot image following: 1. Datasheet of the SoC
signature before 1. Device boots up 2. Technical specifications of
loading. successfully with the the device regarding secure
documented secure boot boot (should consist of keys
process when a valid boot involved and their
image is provided. management life cycle*,
2. Device does not boot signature validation process
up when a tampered boot and any other secure
image (like with missing mechanisms if
signature, invalid implemented.)
signature) is provided.
1.9 Verify usage Verification of the Vendor shall submit the
of documentation provided documentation regarding the
cryptographically by the vendor regarding random generators (either
secure pseudo- the random number hardware based or software
random number generators being used in based or both) being used in
generator on the device. the device with their
embedded device Verification through intended usage.
(e.g., using chip- code-review that random In case, hardware based
provided random number generators or random number generators
number related libraries as are being used, vendors shall
generators). applicable are being used submit the following:
in the device. 1. Datasheet of the SoC
2. Technical specifications of
the device regarding random
generators
In case, software based
random number generators
are being used, vendors shall
provide the libraries being
used for the same.
2. Software/Firmware 2.1 Verify that Testing, in presence of Vendor shall submit the
memory OEM team, to verify the declaration of the memory
protection declared memory protection controls available
controls such as protection controls and enabled in the device.
ASLR and DEP available and enabled in
are enabled by the the device using
embedded/IoT command line-based
operating system, tools/commands or any
if applicable. other open-source tool
like DEP, EMET tool.
2.2 Verify that 1. Verifying that strong The vendor shall submit the
the firmware apps encryption algorithms and specifications and
protect data-in- secure TLS version is documentation related to the
transit using supported by the device to configurations available in
transport layer establish secure the applications and
6 THE GAZETTE OF INDIA : EXTRAORDINARY [PART II—SEC. 3(ii)]

security. communication. firmware related to transport

2. Verifying that device layer security.
properly validates the
server's TLS certificate to
ensure that it is trusted
and has not been
tampered with.
3. Testing for
vulnerabilities which can
affect the security of TLS
connection such as
padding oracle attacks, or
weak cipher suites.
4. Using tools such as
Nmap to identify open
ports through which
device can be accessed
leading to unintended data
retrieval.
5. Verifying that theTLS
session(s) are resistant to
attemptsof interception
and decryption of network
traffic using man-in-the-
middle attacks using tools
like Burpsuite.
2.3 Verify that 1. Identifying the Vendor shall submit a
the firmware apps scenarios when the device document mentioning the
validate the establishes the server use-cases when the device
digital signature connections with the establishes server
of server external world and connections with the external
connections. verifying the following: world, with detailed
• Security information about the
features, related security measures in place
to secure server while validating the digital
connections and signatures of the server
digital signature connections.
validation as
implemented like
strong cipher
suites, secure
TLS version,
SSL pinning etc.
supported by
code
walkthrough.
• Proper certificate
validation,
certificate chain
validation and
certificate
revocation
checks are
implemented in
the device.
2. Testing for
vulnerabilities which can
affect the security of TLS
connection such as
padding oracle attacks, or
weak cipher suites.
[भाग II—खण्ड 3(ii)] भारत का रािपत्र : असाधारण 7
3. Using tools such as
Nmap to identify open
ports through which
device can be accessed

leading to unintended data

retrieval.
4. Verifying that TLS
session(s) are resistant to
attemptsof interception
and decryption of network
traffic using man-in-the-
middle attacks using tools
like Burpsuite.
2.4 Verify that Secure code review [both Vendor shall provide :
any use of banned automated and manual], 1. Firmware binaries for
C functions are in presence of OEM team, code review.
replaced with the using a licensed static
appropriate safe analysis tool through any 2. Internal code review
equivalent of the following reports
functions. approaches:
1. Visit to the evaluation
agency by the vendor
with the firmware code
and installing the licensed
static analysis tool
available with the
evaluation agency in their
systems. [Recommended]
2. Visit to the evaluation
agency by the vendor
with the firmware code
and any licensed static
analysis tool available
with them and
demonstrating the code
review activity in the
presence of
representatives of
evaluation agency.
3. Giving a remote access
of the systems at vendor
site to the evaluation
agency for installing their
licensed static analysis
tool available with them.
4. Giving a remote access
of the systems at vendor
site to the evaluation
agency containing the
firmware code along with
the licensed static analysis
tool available with the
vendors.
2.5 Verify that Verification of the Vendor shall submit the
each firmware submitted list of third- following:
maintains a party components by 1. Documentation for
software bill of running automated tools information on software bill
materials like FACT on the of materials, including third-
cataloging third firmware. party components and
party Identifying vulnerabilities versions.
8 THE GAZETTE OF INDIA : EXTRAORDINARY [PART II—SEC. 3(ii)]

components, in the third-party 2. Organization process and

versioning, and component(s) through policies for the following:
published publically available • Addressing and
vulnerabilities. vulnerability databases patching any
Verification and identified
validation of the process vulnerabilities in
defined by the vendor for third-party
providing regular security components.
updates and patches for • Informing the
the firmware to address customers about the
any known vulnerabilities security issues or
in third-party vulnerabilities and
components. providing security
updates and patches
for the same.
3. Configuration
management system and
related policies for
maintaining firmware and
third-party binaries, libraries
and frameworks along with
the patches/fixes issued to
the devices.
2.6 Verify all Independent secure code Vendor shall provide:
code including review [both automated 1. Firmware binaries for
third-party and manual] using a code review.
binaries, libraries, licensed static analysis 2. Internal code review
frameworks are tool through any of the reports
reviewed for following approaches:
hardcoded 1. Visit to the evaluation
credentials agency by the vendor
(backdoors). with the firmware code
and installing the licensed
static analysis tool
available with the
evaluation agency in their
systems. [Recommended]
2. Visit to the evaluation
agency by the vendor
with the firmware code
and any licensed static
analysis tool available
with them and
demonstrating the code
review activity in the
presence of
representatives of
evaluation agency.
3. Giving a remote access
of the systems at vendor
site to the evaluation
agency for installing their
licensed static analysis
tool available with them.
4. Giving a remote access
of the systems at vendor
site to the evaluation
agency containing the
firmware code along with
the licensed static analysis
tool available with the
vendors.
[भाग II—खण्ड 3(ii)] भारत का रािपत्र : असाधारण 9
2.7 Verify that 1. Identifying the Vendor shall submit a
the firmware apps scenarios when the device document mentioning the
pin the digital establishes the server use-cases when the device
signature to a connections with the establishes server
trusted server(s). external world and connections with the external
verifying the following: world, with detailed
• Security information about the
features, related security measures in place
to secure server while validating the digital
connections and signatures of the server
digital signature connections.
validation as
implemented like
strong cipher
suites, secure
TLS version,
SSL pinning etc.
supported by
code
walkthrough.
• Proper certificate
validation,
certificate chain
validation and
certificate
revocation
checks are
implemented in
the device.
2.7 Verify Testing, in presence of Vendor shall submit the
security controls OEM team, to verify the documentation regarding the
are in place to security controls as security controls in place to
hinder firmware provided by the vendor to hinder firmware reverse
reverse hinder firmware reverse engineering.
engineering engineering.
(e.g.removal of
verbose
debugging
symbols).
2.8 Verify that Testing, in presence of Vendor shall submit the
the firmware OEM team, to verify the measures implemented in the
update process is measures implemented in device to make it resistant to
not vulnerable to the device to make it time-of-check vs. time-of-
time-of-check vs resistant to time-of-check use attacks.
time-of-use vs.time-of-use attacks.
attacks.
2.9 Verify the Testing, in presence of Vendor shall submit the
device uses code OEM team, to verify the process of achieving secure
signing and following: firmware upgrade which
validates 1. Device gets should consist of keys
firmware upgrade successfully updated with involved and their
files before the documented secure management life cycle*,
installing. upgrade process when a signature validation process
valid update package is and any other secure
provided. mechanisms if implemented.
2. Device does not boot
up when a tampered
update package (like with
missing signature, invalid
signature) is provided.
10 THE GAZETTE OF INDIA : EXTRAORDINARY [PART II—SEC. 3(ii)]

2.10 Verify that Testing, in presence of Vendor shall submit the

the device cannot OEM team, to verify that process of achieving secure
be downgraded to the device cannot be firmware upgrade which
old versions (anti- downgraded to old should consist of keys
rollback) of valid versions (anti-rollback) of involved and their
firmware. valid firmware. management life cycle*,
signature validation process
and any other secure
mechanisms if implemented.

2.11 Verify that Verification shall be done Vendor shall provide the
firmware can as per the applicable following:
perform scenario: 1. Modes of updates
automatic Case 1: Automatic OTA available i.e. automatic,
firmware updates updates are available: manual or both.
upon a predefined A standard operating 2. Organizational process
schedule. procedure for issuing and policies regarding the
automatic issuing of updates to the
updates/upgrades to the devices.
in-field devices is
required to be submitted
by the vendor which can
then be evaluated by the
evaluation agency as per
C20, C21 and C22
security requirement of
OWASP open standard.
Case 2: Automatic OTA
updates are not
available and vendor
provides manual
updates:
A standard operating
procedure for issuing
manual updates/upgrades
to the in-field devices is
required to be submitted
by the vendor which can
then be evaluated by the
evaluation agency as per
C20, C21 and C22
security requirement of
OWASP open standard.
3. Secure Process 3.1 Verify that Testing, in presence of Vendors shall provide the
Conformance wireless OEM team, to verify the documentation regarding the
communications process of mutual process of mutual
are mutually authentication as laid authentication as
authenticated. down in the implemented in the device
documentation by the when wireless
vendor. communications are
initiated.
In case, the device does not
support wireless
communications, the vendor
shall provide a declaration
for the same.
3.2 Verify that Identifying all the security Vendors shall provide the
wireless mechanisms being used in documentation regarding the
communications the communication security measures
are sent over an process verification implemented in the device to
encrypted through: prevent tampering of the data
[भाग II—खण्ड 3(ii)] भारत का रािपत्र : असाधारण 11
channel. • Testing, in being sent through wireless
presence of mode of communication.
OEM team
• Code review In case, the device does not
• Process audit of support wireless
the key-life cycle communications, the vendor
process shall provide a declaration
for the same.
3.3 Verify that Vendor shall submit Bill of
whether trusted materials for critical
sources are being hardware components
used for sourcing (related to security functions
the components like SoC).
of the device i.e.
trusted supply
chain through a
managed Bill of
materials for
critical hardware
components
(related to
security functions
like SoC) is in
use.
3.4 Supply chain Vendor shall submit the
risk following:
identification, Supply chain risk
assessment, identification, assessment,
prioritization, and prioritization, and mitigation
mitigation shall documents.
be conducted. Supply chain risk/business
Supply chain continuity planning policy
risk/business documents, playbooks
continuity reflecting how to handle
planning policy supply chain disruption,
documents, post-incident summary
playbooks documents.
reflecting how to
handle supply
chain disruption,
post-incident
summary
documents need
to be submitted
and demonstrate
the same.
3.5 Verify the no Document for Network
proprietary protocols used in the device.
network protocols
are being used in
the device. If yes,
then complete
implementation
details and the
source code for
the same shall be
provided.
4. Security 4.1 Design and Design and architecture
Conformance at architecture documents till the PCBA and
details till the SoC level.
PCBA and SoC
12 THE GAZETTE OF INDIA : EXTRAORDINARY [PART II—SEC. 3(ii)]

product level to be
development stage provided to aid in
counterfeit
mitigation and
malware
detection.
4.2 Threat Process and method
mitigation artifacts need to be
strategies for submitted and
tainted and demonstrate the same.
counterfeit
products shall be
implemented as
part of product
development.
4.3 One or more List of components that
up-to-date have been identified as
malware requiring tracking targets
detection tools of tainting/counterfeiting,
shall be deployed CM tool.
as part of the Quality assurance process
code acceptance need to be submitted and
and development demonstrate the same.
processes.
Malware
detection
techniques shall
be used before
final packaging
and delivery (e.g.,
scanning finished
products and
components for
malware using
one or more up-
to-date malware
detection tools).
4.4 Supply chain Supply chain risk/business
risk continuity planning policy
identification, documents, playbooks
assessment, reflecting how to handle
prioritization, and supply chain disruption,
mitigation shall post-incident summary
be conducted. documents need to be
submitted and demonstrate
the same.

Uploaded by Dte. of Printing at Government of India Press, Ring Road, Mayapuri, New Delhi-110064
and Published by the Controller of Publications, Delhi-110054.