Document No.

Government of India STQC/IoTSCS/F03,

Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Security Requirements for IoT Devices (for security, privacy and supply chain)

IoT device is defined as “an entity of an IoT system that interacts and communicates with the physical
world through sensing or actuating” [Source: ISO/IEC 27400:2022]. With the increasing number of
Internet of Things (IoT) devices and increasing reliance on such devices, the security and privacy risks
relating to those “things” are expected to grow. Their widespread deployment in networks and systems
make them easy and prime targets for cyber-attacks.

This document provides a set of security, privacy and supply chain requirements for IoT devices.
Adhering to these requirements will provide adequate confidence to the users in respect of security,
privacy and supply chain security of these devices.

Not all requirements outlined in this document are universally applicable to every IoT device. Users or
organizations have to assess and determine the specific security, privacy, and supply chain requirements
relevant to their use of these devices.

This document defines four assurance levels, with each level increasing in depth of testing.
Users/organizations can choose the appropriate assurance level depending on area of applicability,
sensitivity of data and operational needs.
• Level 0 is for minimal assurance level. Within 01 year of obtaining Level 0 compliance the IoT
devices has to seek certification for Level 1/Level 2/Level 3
• Level 1 is for low assurance levels and all IoT devices are expected to meet these requirements
• Level 2 is for IoT devices that contain sensitive data, which requires protection and is the
recommended level for most IoT devices
• Level 3 is for the most critical IoT devices - applications that perform high value transactions,
contain sensitive medical data, or any application that requires the highest level of trust.

Each IoT device can undergo certification any of these four levels as provided below:

Certification Testing Level Objective Requirements Methodology

Level
Level 0 Minimal Level 0 provides Annexure A Test Laboratory
certification based on required to verify
declaration and limited declaration are
appropriate and
Page | 1
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Testing/Audit perform limited

testing/audit

Level 1 Basic Level 1 provides Refer Annexure A, Test Laboratory

minimum security, B and C required to verify
privacy and supply chain the claim made by
developer through
requirements for
testing,
adequate confidence to demonstration, site
the user. visit and audit.

Level 2 Intermediate In addition of Level 1 Refer Annexure A, Test Laboratory

requirements, Level B and C required to verify
2provides extra security the claim made by
requirements related to developer through
hardware and software. testing,
It also defines specific demonstration, site
security requirements visit and audit.
pertaining to
Intellectual Property
protection technologies,
reverse engineering,
firmware update
process etc.

Level 3 Advanced In addition of Level 2 Refer Annexure A, Test Laboratory

requirements, Level 3 B and C required to verify
provides extra security the claim made by
requirements related to developer through
hardware and software. testing,
It also defines specific demonstration, site
security requirements visit and audit.
pertaining to side
channel attacks,
Page | 2
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

encrypted inter chip

communication,
tampering etc.

Note:

1. Level 0 certification is valid for only one year and is a onetime occurrence. Developers are
encouraged to pursue Level 1/Level 2/Level 3 certification within this timeframe.

2. Level 1, Level 2, and Level 3 certifications are valid for three years, with one surveillance audit
required each year.

Page | 3
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Annexure ‘A’

Mandatory for All Levels

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
5.1 Requirements
for IoT device
policies and
documentation
5.1.1 Risk
management
5.1.1.1.1 IoT devices a) Verify risk i. Risk
shall have assessment Assessment
documentation and Report
recording the documentat ii. Risk Treatment
results of a risk ion are Plan
assessment complete iii. Risk
process and Assessment
performed at accurate. Methodology
the IoT device b) Check iv. Constraints
level in the implementa Documentatio
context of a tion and n
risk assessment effectivenes v. Review
at the system s of Records
level. controls. vi. Interested
5.1.1.1.2 The risk c) Assess Parties
assessment device Analysis
process shall manageme
take into nt under
account resource
intended constraints.
outcomes for d) Ensure
Page | 4
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
the intended documentat
use case. ion is
5.1.1.1.3 The risk maintained
assessment and
process shall accessible
also take into throughout
account the the device’s
needs and lifecycle.
expectations of
interested
parties (e.g.
those parties
on networks to
which the IoT
device is
connected),
including
physical and
logical
undesired
effects.
5.1.1.1.4 The risk
assessment
shall take into
account that
IoT devices can
be constrained
(e.g. limited
battery, little
memory,
‘weak’ CPU),
Page | 5
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
which informs
the risk
treatment
process.
5.1.1.1.5 Risk
assessment
and treatment
processes shall
be defined and
applied.
5.1.1.1.6 IoT devices
shall
implement the
features and
controls
identified as
necessary in its
Statement of
Applicability, as
well as features
and controls.
5.1.1.1.7 The
documentation
shall be
available for
the supported
lifetime of the
product.
5.1.2 Information
disclosure

Page | 6
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
5.1.2.1.1 IoT devices a) Verify user i. User
shall have user documentat Documentation
documentation ion lists all ii. Security Support
that lists the security and Policy
features that privacy iii. Product Lifecycle
the IoT device features Documentation
provides clearly. iv. Risk Assessment
to support b) Check Report
controls for documentat
security and ion
privacy, making availability
it clear if any of throughout
the IoT device the device’s
requirements support
in 5.2 are not period.
included. c) Confirm the
5.1.2.1.2 Such existence
information and clarity
shall be of the
publicly security
available for support
the period of policy and
time the IoT update
device is discontinua
supported. tion
5.1.2.1.3 IoT devices notices.
shall be
covered by a
security
support policy
and other
Page | 7
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
supporting
documentation
wherein users
are made
aware in
advance of
when security
updates will be
discontinued.
5.1.3 Vulnerability
disclosure and
handling
processes
5.1.3.1.1 IoT devices a) Verify i. Vulnerability
shall have comprehen Disclosure Policy
documentation sive ii. Vulnerability
that defines documentat Handling
the ion for Procedures
vulnerability vulnerabilit iii. Public Reporting
disclosure and y reporting Mechanism
handling and Documentation
processes that handling iv. Product Lifecycle
will apply for processes. Documentation
the supported b) Test
lifetime of the accessibility
device. and
5.1.3.1.2 Vulnerability functionalit
disclosure and y of the
handling public
processes shall reporting
include, at a system.
Page | 8
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
minimum, a c) Ensure
capability to defined
receive reports steps for
of potential acknowledg
vulnerabilities ing,
from the assessing,
public. and
resolving
vulnerabiliti
es.
d) Confirm
adherence
to relevant
standards
and
regulations.
5.2 Requirements
for IoT device
capabilities
and operations
5.2.1 It includes IoT
device features
to be used
with a risk
assessment
and treatment
process in
accordance
with 5.1.1.
5.2.2 Configuration

Page | 9
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
5.2.2.1.1 If the a) Test that i. Access Control
configuration only Policy
settings of the authorized ii. Authorization
IoT device can entities can Procedures
be modified, modify the iii. Configuration
only authorized device’s Management
entities shall be configuratio Documentation
able to modify n settings.
the b) Validate
configuration that
settings of the configuratio
IoT device. n changes
5.2.2.1.2 If IoT devices affecting
are capable of other
changing the devices are
configuration permitted
of IoT and only when
other devices, properly
they shall only authorized.
be capable of
making such
changes when
authorized.
5.2.3 Software reset
5.2.3.1.1 If IoT devices a) Verify that i. Reset Procedure
have the the reset Documentation
capability to be process is ii. Authorization and
reset, that secure and Access Control
process shall prevents Policy
be secure. unauthorize
5.2.3.1.2 This capability d access.
Page | 10
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
shall only be b) Confirm
executable by that only
an authorized authorized
entity. entities can
initiate the
reset
process.
5.2.4 User data
removal
5.2.4.1.1 If the IoT a) Verify that i. Data Deletion
device stores the device Procedure
user data, it provides a ii. Access Control
shall provide a function to Policy
function for delete user
deleting data from
appropriate all types of
user data memory.
stored on the b) Ensure that
device in any the data
type of deletion
memory. function is
5.2.4.1.2 The function accessible
shall be only to
restricted to authorized
authorized entities.
entities only.
5.2.5 Protection of
data
5.2.5.1.1 IoT devices a) Verify that i. Data Protection
shall be the device Policy
capable of employs ii. Software Security
Page | 11
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
protecting the mechanism Documentation
data they store s to protect iii. Cryptographic
and transmit stored and Implementation
from transmitted Guidelines
unauthorized data (e.g.,
access, encryption,
modification access
and disclosure. controls).
5.2.5.1.2 This shall b) Confirm
include that the
configuration device’s
settings, software
identifying and
data, user data, firmware
event logs and are secured
sensitive against
security unauthorize
parameters. d access
5.2.5.1.3 IoT devices and
shall be modificatio
capable of n.
protecting their c) Check the
software implementa
(including tion of
firmware) from cryptograph
unauthorized ic measures
access and (encryption,
modification. hashing,
5.2.5.1.4 IoT devices digital
shall use signatures)
cryptography for
Page | 12
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
(e.g. safeguardin
encryption g data
with integrity
authentication, and
cryptographic confidential
hashes, digital ity.
signature
validation) to
prevent the
confidentiality
and integrity of
data requiring
protection
from being
compromised.
5.2.6 Interface
access
5.2.6.1.1 IoT devices a) Verify i. Access Control
shall have mechanism Policy
mechanisms to s for ii. Authentication and
limit logical restricting Authorization
access to its logical Procedures
interfaces to access to iii. Identifier
authorized interfaces Management and
entities only. and ensure Security Policy
5.2.6.1.2 IoT devices only iv. Default Values and
shall employ authorized Parameter
appropriate entities can Management
authentication access Documentation
and access them.
control b) Assess the
Page | 13
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
mechanisms. implementa
5.2.6.1.3 Security and tion of
privacy authenticati
requirements on and
shall be access
assessed when control
designing and mechanism
implementing s to confirm
the functions they are
of IoT devices appropriate
regarding and
creation and effective.
use of c) Ensure that
identifiers. unique
5.2.6.1.4 IoT devices identifiers
shall ensure are created
that common and
values for common
critical security values for
parameters, security
such parameters
as global are
private keys or replaced
standard with unique
passwords, are or external
replaced by values
values that are before
unique per deployment
device or .
explicitly
defined by an
Page | 14
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
appropriate
external entity
before they are
put into
operation.
5.2.7 Software and
firmware
updates
5.2.7.1.1 If the IoT a) Verify that i. Software Update
device software Procedure
supports updates are ii. Authorization
software performed Policy for Updates
updates, using iii. Update Failure
updates shall secure Recovery Plan
be performed procedures,
using a secure including
procedure. encryption
5.2.7.1.2 Updates shall and
only be integrity
initiated by checks.
authorized b) Ensure that
entities. only
5.2.7.1.3 Unexpected authorized
interruption of entities can
an update shall initiate
leave the IoT software
device in a updates.
state that c) Assess the
minimizes device's
potential for ability to
harm, taking handle
Page | 15
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. No. Requirements What to be Tested/ Documents Required Implementation Comment

for IoT security audited Details/Evidences by
and privacy — Submitted Developer
Device
baseline
requirements
into account unexpected
the risks of the interruption
IoT device not s during
functioning as updates,
expected. ensuring it
minimizes
potential
harm and
maintains
operational
integrity.

Page | 16
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Annexure B

Below Security Requirements need to be selected based on Levels

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
Level 1/2/3
1. Verify that a) Identification of i. Datasheet of the SoC
application the availability of being used in the device.
layer debugging debugging ii. Documentation related to
interfaces such interfaces such as ports/interfaces enabled in
USB, UART, and USB, UART, and the production devices and
other serial other serial the related access control
variants are variants through mechanism for protection
disabled or the Datasheet of of the same.
protected by a the SoC being iii. Process flow of the
complex used in the device Manufacturing/Provisioning
password. under test. of the device
b) Verification and
validation of the
ports/interfaces
enabled in the
production
devices and the
related access
control
mechanism for
protection of the
same as declared
in the vendor
documentation.
c) Testing, in
presence of OEM
team, to verify the
enabling/disabling
of all the ports and
Page | 17
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
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.
d) 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.]
Page | 18
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
2. Verify that Identifying all the keys i. List of all keys and
cryptographic and certificates being used in
keys and certificates being used the device ecosystem
certificates are in ii. Key management life cycle
unique to each the device eco-system (purpose, generation,
individual and storage, destruction/
device. verification through: zeroization, validity, key
a) Testing, in changeover/rotation)
presence of OEM
team
b) Code review
c) Process audit of
the key-life cycle
process
3. Verify that Testing, in presence of Declaration of the memory
memory OEM team, to verify protection controls available and
protection the declared memory enabled in the device.
controls such as protection controls
ASLR and DEP available and enabled
are enabled by in the device using
the command line-based
embedded/IoT tools/commands or
operating any other open-source
system, if tool like DEP, EMET
applicable. tool.
4. Verify that on- a) Identification of i. Datasheet of the SoC
chip debugging the availability of being used in the device.
interfaces such debugging ii. Documentation related to
as JTAG or SWD interfaces such as ports/interfaces enabled in
are disabled or USB, UART, and the production devices and
that available other serial the related access control
protection variants through mechanism for protection
mechanism is the Datasheet of of the same.
enabled and the SoC being iii. Process flow of the
Page | 19
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
configured used in the device Manufacturing/Provisioning
appropriately. under test. of the device
b) Verification and
validation of the
ports/interfaces
enabled in the
production
devices and the
related access
control
mechanism for
protection of the
same as declared
in the vendor
documentation.
c) 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.
d) Process audit of
the manufacturing
Page | 20
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
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.]
5. Verify that Identifying whether i. Datasheet of the SoC being
trusted TEE/SE/TPM is used in the device.
execution is available or not in the ii. User manual/ Technical
implemented device through specifications of the device
and enabled, if the SoC datasheet and iii. Code snippets of the TEE
available on the technical API call, wherever
device SoC or documentation applicable
CPU. submitted by the
vendor.
Further assessment is
done on the basis of
scenarios as applicable
to device as
defined below:
Page | 21
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
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
nonconformance to
the
requirement. OEM is
required to enable and
implement the
TEE/SE/TPM.
6. Verify that Identifying all the keys i. List of all keys and
sensitive data, and certificates being used in
private keys and certificates being used the device ecosystem
certificates are in ii. List of all the sensitive data
stored securely the device eco-system with their intended usage and
in a Secure and secure storage
Element, TPM, verification through: mechanism(s) as
TEE (Trusted a) Testing, in implemented along with
Execution presence of OEM secure configurations to be
Environment), team enabled in the device.
or protected b) Code review iii. Key management life
using strong c) Process audit of cycle (purpose, generation,
cryptography. the key-life cycle storage, destruction/

Page | 22
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
process zeroization, validity, key
changeover/rotation)
private keys and
certificates.
7. Verify that the a) Verifying that Specifications and documentation
firmware apps strong encryption related to the configurations
protect data-in- algorithms and available in the applications and
transit using secure TLS version firmware related to transport layer
transport layer is supported by security.
security. the device to
establish secure
communication.
b) Verifying that
device properly
validates the
server's TLS
certificate to
ensure that it is
trusted and has
not been
tampered with.
c) Testing for
vulnerabilities
which can affect
the security of TLS
connection such
as padding oracle
attacks, or weak
cipher suites.
d) Using tools such as
Nmap to identify
open ports
through which
device can be
Page | 23
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
accessed leading
to unintended
data retrieval.
e) Verifying that the
TLS session(s) are
resistant to
attempts of
interception and
decryption of
network traffic
using man-in-the
middle attacks
using tools like
Burpsuite.
8. Verify that the a) Identifying the Document mentioning the
firmware apps scenarios when use cases when the device
validate the the device establishes server connections with
digital signature establishes the the external world, with detailed
of server server connections information about the security
connections. with the external measures in place while validating
world and the digital signatures of the server
verifying the connections.
following:
• Security
features,
related to
secure server
connections
and digital
signature
validation as
implemented
like strong
cipher
Page | 24
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
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.
b) Testing for
vulnerabilities
which can affect
the security of TLS
connection such
as padding oracle
attacks, or weak
cipher suites.
c) Using tools such as
Nmap to identify
open ports
through which
device can be
accessed leading
to unintended
data retrieval.
d) Verifying that TLS
Page | 25
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
session(s) are
resistant to
attempts of
interception and
decryption of
network traffic
using man-in-the
middle attacks
using tools like
Burpsuite.
9. Verify that Testing, in presence of The documentation regarding the
wireless OEM team, to verify process of mutual authentication
communication the process of mutual as
s are mutually authentication as laid implemented in the device
authenticated. down in the when wireless communications are
documentation by the initiated.
vendor. In case, the device does not
support wireless communications,
the vendor shall provide a
declaration for the same.
10. Verify that Identifying all the i. Documentation regarding
wireless security mechanisms the security measures
communication being used in the implemented in the device
s are sent over communication to prevent tampering of
an encrypted process the data being sent
channel. verification through: through wireless mode of
a) Testing, in communication.
presence of ii. In case, the device does
OEM team not support wireless
b) Code review communications, the
c) Process audit vendor shall provide a
of the key-life declaration for the same.
cycle process
11. Verify that any Secure code review i. Firmware binaries for code
Page | 26
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
use of banned C [both automated and review.
functions are manual], in presence ii. Internal code review
replaced with of OEM team, reports
the appropriate using a licensed static
safe equivalent analysis tool through
functions. any of the following
approaches:
a) 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.
[Recommende
d]
b) 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
Page | 27
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
review activity
in the
presence of
representative
s of evaluation
agency.
c) Giving a
remote access
of the systems
at vendor site
to the
evaluation
agency for
installing their
licensed static
analysis tool
available with
them.
d) 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.
12. Verify that each a) Verification of i. Documentation for
firmware the submitted information on software
Page | 28
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
maintains a list of third- bill of materials, including
software bill of party third-party components
materials components and versions.
cataloging third- by running ii. Organization process and
party automated policies for the following:
components, tools like FACT • Addressing and patching
versioning, and on the any identified
published firmware. vulnerabilities in third-
vulnerabilities. b) Identifying party components.
vulnerabilities • Informing the customers
in the third- about the security issues or
party vulnerabilities and
component(s) providing security updates
through and patches for the same.
publically iii. Configuration management
available system and related policies
vulnerability for maintaining firmware
databases. and third-party binaries,
c) Verification libraries and frameworks
and validation along with the
of the process patches/fixes issued to the
defined by the devices.
vendor for
providing
regular
security
updates and
patches for
the firmware
to address any
known
vulnerabilities
in third party
components.
Page | 29
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
13. Verify all code Secure code review i. Firmware binaries for code
including third- [both automated and review.
party binaries, manual], in presence ii. Internal code review
libraries, of OEM team, reports
frameworks are using a licensed static
reviewed for analysis tool through
hardcoded any of the following
credentials approaches:
(backdoors). a) 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.
[Recommende
d]
b) Visit to the
evaluation
agency by the
vendor with
the firmware
code and any
licensed static
analysis tool
available with
them and
demonstrating
Page | 30
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
the code
review activity
in the
presence of
representative
s of evaluation
agency.
c) Giving a
remote access
of the systems
at vendor site
to the
evaluation
agency for
installing their
licensed static
analysis tool
available with
them.
d) 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.
14. Verify that the Independent secure i. Firmware binaries for code
Page | 31
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
application and code review [both review
firmware automated and ii. Internal code review
components are manual] using a reports
not susceptible licensed static analysis
to OS Command tool through any of
Injection by the following
invoking shell approaches:
command a) Visit to the
wrappers, evaluation
scripts, or that agency by the
security vendor with
controls prevent the firmware
OS Command code and
Injection. installing the
licensed static
analysis tool
available with
the evaluation
agency in their
systems.
[Recommende
d]
b) 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
Page | 32
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
review activity
in the
presence of
representative
s of evaluation
agency.
c) Giving a
remote access
of the systems
at vendor site
to the
evaluation
agency for
installing their
licensed static
analysis tool
available with
them.
d) 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.
Level 2/3
15. Verify that the Identifying the Document mentioning the use-
Page | 33
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
firmware apps scenarios when the cases when the device establishes
pin the digital device establishes the server connections with the
signature to a server connections external world, with detailed
trusted with information about the security
server(s). the external world and measures in place while validating
verifying the the digital signatures of the server
following: connections.
a) Security
features,
related to
secure server
connections
and digital
signature
validation as
implemented
like strong
cipher suites,
secure TLS
version, SSL
pinning etc.
supported by
code
walkthrough.
b) Proper
certificate
validation,
certificate
chain
validation and
certificate
revocation
checks are
implemented
Page | 34
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
in the device.
16. Verify the Testing, in presence of i. Measures available in the
presence of OEM team, to verify device to prevent software
tamper the measures tampering.
resistance implemented in ii. Measures available in the
and/or tamper the device to prevent device to prevent
detection software and hardware tampering.
features. hardware tampering.
17. Verify that any Testing, in presence of i. Datasheet of the SoC
available OEM team, to verify ii. Documentation regarding
Intellectual the enabling of the the Intellectual Property
Property Intellectual protection technologies
protection Property protection provided by the chip
technologies technologies provided manufacturer which have
provided by the by the chip been enabled.
chip manufacturer, if iii. In case, no Intellectual
manufacturer available. Property protection
are enabled. technologies are being
provided by the chip
manufacturer, then a
declaration stating the
same.
18. Verify security Testing, in presence of Documentation regarding the
controls are in OEM team, to verify security controls in place to hinder
place to hinder the security controls firmware reverse engineering.
firmware as provided by the
reverse vendor to hinder
engineering firmware reverse
(e.g., removal of engineering.
verbose
debugging
symbols).
19. Verify the Testing, in presence of i. Datasheet of the SoC
device validates OEM team, to verify ii. Technical specifications of
Page | 35
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
the boot image the following: the device regarding
signature before a) Device boots secure boot (should consist
loading. up of keys involved and their
successfully management life cycle,
with the signature validation
documented process
secure boot and any other secure
process when mechanisms if
a valid boot implemented.)
image is
provided.
b) Device does
not boot up
when a
tampered
boot image
(like with
missing
signature,
invalid
signature) is
provided.
20. Verify that the Testing, in presence of Process of achieving secure
firmware OEM team, to verify firmware upgrade which should
update process the following: consist of keys involved and their
is not a) Device gets management life cycle, signature
vulnerable to successfully validation process and any other
time-of-check vs updated with secure mechanisms if
time-of-use the implemented.
attacks. documented
secure
upgrade
process when
a valid update
Page | 36
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
package is
provided.
b) Device does
not boot up
when a
tampered
update
package (like
with missing
signature,
invalid
signature) is
provided.
21. Verify the Testing, in presence of Process of achieving secure
device uses OEM team, to verify firmware upgrade which should
code signing the following: consist of keys involved and their
and validates a) Device gets management life cycle, signature
firmware successfully validation process and any other
upgrade files updated with secure mechanisms if
before the implemented.
installing. documented
secure
upgrade
process when
a valid update
package is
provided.
b) Device does
not boot up
when a
tampered
update
package (like
with missing
Page | 37
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
signature,
invalid
signature) is
provided.

22. Verify that the Testing, in presence of Process of achieving secure

device cannot OEM team, to verify firmware upgrade which should
be downgraded that the device cannot consist of keys involved and their
to old versions be management life cycle, signature
(anti-rollback) downgraded to old validation process and any other
of valid versions (anti-rollback) secure mechanisms if
firmware. of valid firmware. implemented.
23. Verify usage of a) Verification of Documentation regarding the
cryptographicall the random generators (either
y secure documentatio hardware based or software based
pseudo-random n provided by or both) being used in the device
number the vendor with their intended usage. In case,
generator on regarding the hardware based random number
embedded random generators are being used, vendors
device (e.g., number shall submit the following:
using chip- generators i. Datasheet of the SoC
provided being used in ii. Technical specifications of
random number the devices. the device regarding
generators). b) Verification random generators
through code In case, software based
review that random number
random generators
number are being used, vendors
generators or shall provide the libraries
related being used for the same.
libraries as
applicable are
being used in
Page | 38
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
the device.
24. Verify that Verification shall be i. Modes of updates available
firmware can done as per the i.e. automatic, manual or
perform applicable scenario: both.
automatic Case 1: Automatic ii. Organizational process and
firmware OTA policies regarding the
updates upon a updates are available: issuing of updates to the
predefined A standard operating devices.
schedule. procedure for issuing
automatic
updates/upgrades
to the in-field devices
is required to be
submitted by the
vendor which can then
be evaluated by the
evaluation agency
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
Level 3
25. Verify that the a) Confirm that i. Tampering Detection and
Page | 39
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
device wipes the device can Response Procedure
firmware and detect ii. Invalid Message Handling
sensitive data tampering and Data Wiping Policy
upon detection events and
of tampering or triggers a
receipt of firmware and
invalid message. sensitive data
wipe.
b) Verify that the
device wipes
firmware and
sensitive data
upon receipt
of an invalid
message or
command.
26. Verify that only a) Ensure i. Datasheets
micro datasheets ii. Reference Manuals
controllers that and reference iii. Configuration Guidelines
support manuals iv. Security feature
disabling confirm the descriptions
debugging capability to
interfaces (e.g. disable JTAG
JTAG, SWD) are or SWD
used. interfaces.
b) Check that the
firmware or
configuration
settings
include
options to
disable
debugging
interfaces.
Page | 40
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
c) Verify the
presence and
effectiveness
of any security
features or
mechanisms
related to
disabling
debugging.
27. Verify that only a) Check i. Datasheets,
micro datasheets ii. Security Feature
controllers that and security Specifications
provide documentatio iii. Any relevant security
substantial n to confirm evaluation or certification
protection from that the reports
de-capping and microcontrolle
side channel r includes
attacks are features like
used. physical
protection
against de-
capping and
side-channel
attack
mitigation
(e.g., voltage
and
temperature
monitoring).
b) Evaluate if the
microcontrolle
r implements
security
mechanisms
Page | 41
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
such as secure
key storage,
hardware
random
number
generators,
and tamper
detection.
c) Perform or
review results
of any security
evaluations or
certifications
that assess
resilience
against
physical
attacks and
side-channel
vulnerabilities.
28. Verify that a) Review the i. PCB Design Documentation
sensitive traces PCB design ii. Trace Exposure Inspection
are not exposed files and Report
to outer layers schematics to iii. Security Design Review
of the printed ensure that Report
circuit board. sensitive
traces are
routed on
inner layers
rather than
outer layers.
b) Inspect the
PCB layers
visually or
Page | 42
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
using X-ray
imaging (if
available) to
confirm that
sensitive
traces are
indeed
protected
within inner
layers and not
exposed.
c) Verify
adherence to
design rules
that specify
trace routing
and layer
usage for
sensitive
signals.
29. Verify that a) Ensure that i. Encryption Protocol
inter-chip the encryption Specification
communication methods used ii. Communication Security
is encrypted for inter-chip Audit Report
(e.g. Main board communicatio iii. Data Integrity Verification
to daughter n meet Records
board security
communication) standards and
. are properly
implemented.
b) Verify that
data
transmitted
between the
Page | 43
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
main board
and the
daughter
board remains
secure and
unaltered.
30. Verify the a) Confirm that i. Code Signing Policy
device uses the device ii. Validation Process
code signing uses code Documentation
and validates signing to iii. Code Signing Audit Report
code before authenticate
execution. software and
firmware
before
execution.
b) Verify that the
device
performs code
validation
checks to
ensure that
only signed
and verified
code is
executed.
31. Verify that a) Confirm that i. Memory Management
sensitive sensitive Policy
information information in ii. Data Overwriting
maintained in memory is Procedures
memory is securely iii. Security and Privacy Audit
overwritten overwritten Report
with zeros as with zeros
soon as it is no once it is no
longer required. longer
Page | 44
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
needed.
b) Ensure that
the
mechanism
for
overwriting
data with
zeros is
functioning
correctly and
effectively
clears
sensitive
information.
32. Verify that the a) Confirm that i. Kernel Container
firmware apps the firmware Configuration Guide
utilize kernel applications ii. Application Isolation
containers for are using Verification Report
isolation kernel iii. Firmware Security
between apps. containers to Assessment Report
ensure
isolation
between
different apps.
b) Verify that the
kernel
containers
effectively
separate the
applications to
prevent
unauthorized
access or
interference.
Page | 45
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
33. Verify that a) Confirm that i. Build Configuration Files
secure compiler secure ii. Compiler Flags Compliance
flags such as - compiler flags Report
fPIE, -fstack- such as -fPIE, - iii. Firmware Security Review
protector-all, - fstack- Report
Wl,-z, protector-all, -
noexecstack, - Wl,-
Wl, -z, z,noexecstack,
noexecheap are and -Wl,-
configured for z,noexecheap
firmware builds. are properly
configured in
the firmware
build process.
b) Ensure that
the firmware
build process
incorporates
these flags to
enhance
security and
protect
against
common
vulnerabilities.
34. Verify that a) Confirm that i. Code Protection
micro microcontrolle Configuration
controllers are rs are Documentation
configured with configured ii. Microcontroller Security
code protection with code Settings Report
(if applicable). protection iii. Code Protection
mechanisms Implementation
where Verification Report
applicable to
Page | 46
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Cl. Verification What to be Documents Required Implementation Comment

No. Requirements tested/audited Details/Evidence by
s Submitted Developer
safeguard
against
unauthorized
access or
tampering.
b) Verify that the
implemented
code
protection
measures are
effectively
preventing
unauthorized
code
modifications
or access.

Page | 47
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

Annexure C
Supply Chain Security Requirements

Sr. Requirements What to be Documents Required Implementation Comment by

No. Tested/audited Details Developer
SC1 Verify that whether Bill of materials for
trusted sources are critical hardware
being used for sourcing components (related
the components of the
to security functions
device i.e. trusted
supply chain through a like SoC).
managed Bill of
materials for critical
hardware components
(related to security
functions like SoC) is in
use.
SC2 Supply chain risk Supply chain risk
identification, identification,
assessment, assessment,
prioritization and
prioritization, and
mitigation shall be
conducted. Supply mitigation
chain risk/business documents.
continuity planning
policy documents, Supply chain
playbooks reflecting risk/business
how to handle supply continuity planning
chain disruption, post- policy documents,
incident summary playbooks reflecting
documents need to be how to handle supply
submitted and
chain disruption,
demonstrate the same.
post-incident
summary

Page | 48
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

documents.

SC3 Verify the no Document for

proprietary network Network protocols
protocols are being used in the device.
used in the device. If
yes, then complete
implementation details
and the source code
SC4 Design and architecture Design and
details till the PCBA and architecture
SoC level to be documents till the
provided to aid in
PCBA and SoC level.
counterfeit mitigation
and malware detection.
SC5 Threat mitigation Process and
strategies for tainted methodartifacts need to
and counterfeit be submitted and
products shall be
demonstrate the same.
implemented as part of
product development.
SC6 One or more up-to- List of components
date malware detection thathave been identified
tools shall be deployed as requiring tracking
as part of the code
targets of
acceptance and
development tainting/counterfeiting,
processes. Malware CM tool.
detection techniques
shall be used before Quality assurance process
final packaging and need to be submitted and
delivery (e.g., scanning demonstrate the same.
finished products and
components for
malware using one or
more up-to-date
malware detection
Page | 49
 Document No.
Government of India STQC/IoTSCS/F03,
Ministry of Electronics & IT (MeitY) Issue No. 04
STQC Directorate Date: 13-09-2024
IT &eGov Division

Technical Construction File (TCF) for IoT Device

tools).
SC7 Supply chain risk Supply chain
identification, risk/business
assessment, continuity planning
prioritization, and policy documents,
mitigation shall be playbooks reflecting
conducted. how to handle supply
chain disruption,
post-incident
summary documents
need to be
submitted and
demonstrate
the same.

References

1. ISO/IEC 27400 Cybersecurity — IoT security and privacy — Guidelines

2. ISO/IEC 27402 Cybersecurity — IoT security and privacy — Device baseline requirements
3. OWASP ASVS Appendix C: IoT security Requirements
4. ISO/IEC 20243 - Information technology — Open Trusted Technology ProviderTM Standard (O-
TTPS)

Page | 50