Common Cybersecurity Requirements in IoT Standards, Best Practices,

and Guidelines

Rauli Kaksonen

, Kimmo Halunen

and Juha R

oning

University of Oulu, Oulu, Finland

Keywords:

Internet of Things, IoT, Cybersecurity, Security Requirements, Standards, Best Practices, Guidelines.

Abstract:

The cybersecurity of the Internet of Things (IoT) is an increasing concern and product vendors are advised

to follow security standards, best practices, and guidelines. From the many requirement sources, a vendor is

likely to choose only a few. How does this selection impact the security requirements of an IoT product? To

answer the question, we collect requirements from 16 sources and divide them into categories for comparison.

Common categories are identiﬁed, with all sources covering Security design, Interface security, Authentica-

tion, Data protection, and System updates. The agreement on the high-level categories does not hold in the

subcategories and the selection of the sources have a big impact to the requirement details. Consolidation of

the IoT security requirements would be desirable and possible.

1 INTRODUCTION

As more devices are connected to the Internet of

Things (IoT), their cybersecurity is an increasing con-

cern. IoT has a great impact on the safety, security,

and privacy of people (ENISA, 2017; NIST, 2018).

There are many cases of IoT security breaches and

the vendors do not appear to have security as a key

requirement (Sayegh, 2021). Momenzadeh et. al. ex-

amined two IoT devices and concluded that would

they have followed some well-known security best

practices, they would be more secure (Momenzadeh

et al., 2020). Stellios et. al. performed a survey of

IoT cyberattacks and noted that the majority of at-

tacks could be mitigated if the existing security mech-

anisms and standards would have been properly im-

plemented (Stellios et al., 2018).

In addition to countless Internet sites, there are

many sources of IoT security requirements, such as

academic studies (Momenzadeh et al., 2020; Stellios

et al., 2018; Tange et al., 2020). System builders

and administrators have their sources, e.g. from NIST

(NIST, 2018). Organizations like ENISA, NIST, and

many others have published requirements for IoT

product security (ENISA, 2017; NIST, 2020). For

practical reasons, IoT vendors are likely to choose

https://orcid.org/0000-0001-8692-763X

https://orcid.org/0000-0003-1169-5920

https://orcid.org/0000-0001-9993-8602

just a few sources for requirements. How does this

selection impact the security requirements for an IoT

product? How much work it is to cover additional re-

quirement sources? This depends on how much the

requirements differ between the sources, but this does

not appear to be studied. To ﬁll the gap, this study

aims to answer the following research questions:

1. Is there a consensus on security requirements in

security standards, guidelines, best practices, and

other sources?

2. What are the common security requirements?

3. How well do the sources cover the common secu-

rity requirements?

4. How much do the security requirements differ be-

tween the sources?

2 METHODS

2.1 Security Requirements and

Categories

To answer the research questions, we need to analyze

IoT security requirement sources, such as standards,

guidelines, and best practices. For a source to be in-

cluded it has to cover security broadly, e.g. not only

privacy or data protection. The source has to be au-

thored by a respected organization, such as a govern-

Kaksonen, R., Halunen, K. and Röning, J.

Common Cybersecurity Requirements in IoT Standards, Best Practices, and Guidelines.

DOI: 10.5220/0011041700003194

In Proceedings of the 7th International Conference on Internet of Things, Big Data and Security (IoTBDS 2022), pages 149-156

ISBN: 978-989-758-564-7; ISSN: 2184-4976

149

ment body or industry consortium, and available with-

out a fee. The source must be from the year 2016 or

newer. Sources use various terms, e.g. security prin-

ciples, controls, capabilities, but security requirement

is the most common term and used in this paper. The

style in the sources vary, e.g. consider the following

requirements.

“Apply authentication functions for each IoT

system or service that will ensure the security

of the entire IoT system or service” (IoTAC,

2016)

“Conﬁrm that the device supports user authen-

tication to be able to make changes to the de-

vice conﬁguration with the goal to require au-

thentication before changes are made, reduc-

ing risk to the device that anyone can walk up

and make anonymous changes to the device.”

(CTIA, 2021)

“Authentication mechanisms used to authenti-

cate users against a device shall use best prac-

tice cryptography, appropriate to the proper-

ties of the technology, risk and usage.” (ETSI,

2020)

The differences make it hard to determine when

sources share the same requirement. As a solution, re-

quirements are divided into categories, such as cryp-

tography and authentication, which can be compared

across sources. Complex requirements are split into

individual requirements each matching a single cate-

gory. In the rest of this article, the term requirement

generally means the individual requirement.

The categories in requirements can be generic or

speciﬁc, e.g. passwords is more speciﬁc than au-

thentication. To capture this, the categories are ar-

ranged into a taxonomy where the speciﬁc categories

are linked to the generic ones. A category can be spe-

ciﬁc for several generic categories, e.g. encrypt pass-

words is speciﬁc for cryptography, passwords and

protect security secrets. A category without more

generic categories is a base category. All recursively

resolved speciﬁc categories for category c are the sub-

categories of c. The category itself belongs to its sub-

categories. The taxonomy allows addressing the prob-

lem that related requirements in different sources can

go to different subcategories. None of the subcate-

gories may be popular enough to show in the results.

However, a generic category aggregates the popular-

ity of its subcategories and may then appear in the

results.

Many sources refer to other sources, e.g. Cyber-

security Label references selected requirements from

ETSI EN 303 645 (NCSC-FI, 2021; ETSI, 2020).

Reading the sources, it is clear that the authors still

use their knowledge to choose the referenced require-

ments, thus contributing to the accumulated knowl-

edge.

2.2 Randomness of Categories

Let C be the population of security requirement cat-

egories, S the set of sources, and C

the set of cate-

gories used in source s. The ﬁrst research question

translates to whether there is a consensus on the re-

quirement categories in the sources. The null hy-

pothesis is that source categories C

appear to be ran-

domly chosen from C. Surely no author writes ran-

dom requirements, but without common preferences,

the sources do not correlate and categories appear

to be randomly chosen. To test the null hypothesis,

we calculate the probability of sharing categories by

chance. The probability of randomly choosing any

category for source s is p

|C|

. The population

C is larger than the observed categories if there ex-

ists requirement categories authors considered but ul-

timately none included. Let p

be the probability of

category being shared exactly by n sources. Its ex-

pected value is calculated by summing up the proba-

bilities of all source combinations where a category is

present n times,

E(p

) =

∑

K∈S

∏

s∈S



, s ∈ K

1 − p

, s /∈ K

, (1)

where K iterates through values of S

= {A ∈

P(S)



|A| = n}, the set of combinations of exactly n

sources. P(S) is the power set of S. The factor for

each source is either p

or 1 − p

depending whether

the category is present in the source or not. Assum-

ing the category probabilities are independent, the ex-

pected value for the number of categories shared by n

sources c

E(c

) = |C|E(p

). (2)

Once we have the real data from the sources, we can

calculate the actual category distribution and see if it

matches the random distribution or not.

3 RESULTS

We identiﬁed 16 requirement sources that matched

our criteria. The sources cover many IoT domains:

consumer, industrial control systems (ICS), vehi-

cle, medical, and generic IoT. The sources contain

1525 original security requirements, 2243 individ-

ual requirements, and 269 categories. Table 1 lists

the sources and their industry domain, requirement

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

150

Table 1: Requirement sources. For each source, the table gives domain, requirement count, category count, and proportion

of categories shared by other sources. Row “Source average” gives the source average values. Row “Total” gives the total

requirement count, total category count, and proportion of all categories shared by a different number of sources.

Source Domain Require- Security not shared shared shared

ments categories shared by 2-5 by 6-9 10-

C2 IoT Security Baseline (CSDE, 2019) Generic 30 28 0 21% 54% 25%

CTIA Cybersecurity Test Plan (CTIA, 2021) Generic 42 30 7% 40% 20% 33%

Cybersecurity Label (NCSC-FI, 2021) Consumer 26 23 0 17% 48% 35%

ENISA Security Baseline (ENISA, 2017) Generic 129 91 4% 40% 40% 16%

ETSI EN 303 645 (ETSI, 2020) Consumer 90 58 5% 33% 40% 22%

FDA Draft Guidance (FDA, 2018) Health 132 77 1% 40% 42% 17%

GSMA IoT Security Assessment (GSMA, 2018) Generic 437 117 7% 47% 32% 14%

ISASecure CSA (ISASecure, 2019) ICS 351 109 5% 46% 36% 14%

IMDA IoT Cyber Security Guide (IMDA, 2020) Generic 95 80 6% 34% 41% 19%

Internet Society IoT Trust (IS, 2017) Generic 85 60 2% 42% 40% 17%

IoT Security Initiative (IoTSI, 2018) Generic 67 49 4% 43% 37% 16%

IoTSC Security Compliance (IoTSF, 2020) Generic 366 125 6% 48% 34% 12%

IoT Acceleration Consortium (IoTAC, 2016) Generic 63 30 10% 37% 33% 20%

NCSC Health Requirements (NCSC-FI, 2019) Health 230 104 17% 40% 32% 11%

NHTSA Best Practises (NHTSA, 2020) Vehicle 73 42 5% 40% 38% 17%

NISTIR 8259a (NIST, 2020) Generic 27 18 0 44% 11% 44%

Source average 140 65 5% 38% 36% 21%

Total 2243 269 23% 51% 20% 6%

counts, and category counts. The requirement counts

per source vary from 26 to 437 and category counts

from 18 to 125 with averages 140 requirements and

65 categories. A source with many requirements also

has many categories. The table shows separately the

count of categories unique for a source and shared be-

tween 2-5, 6-9, and 10 or more sources. On average, a

source has 5% unique categories. From all categories,

74% are in ﬁve or fewer sources.

3.1 Hypopthesis Veriﬁcation

The null hypothesis is that the source categories are

randomly chosen. Testing of the hypothesis requires a

value for the category population size |C| which min-

imum value is 269, the number of categories we ob-

served in the sources. Different sizes were checked by

using equation 2 to calculate the expected E(c

) for

n = 1,2,...,15. The values were compared with the

observed number of shared categories in the sources.

The smallest cumulative difference was with |C| =

291. Table 2 shows the observed number of cat-

egories, expected value, standard deviation, and p-

value for the number of categories shared by n sources

with the population size 291. For this and other pop-

ulation counts the observed and expected values meet

on a few values of n, but are signiﬁcantly different

on most. It is highly unlikely that the observed cate-

gory distribution results randomly. We reject the null

hypothesis, there exists a set of common requirement

categories shared by the sources.

Table 2: Observed number of categories c

, expected values

E(c

), standard distribution SD(c

), and p-values for cate-

gories shared by n sources and population size |C

| = 291.

Symbol ε stands for p-values smaller than 0.001.

n Observed c

E(c

) SD(c

) p

0 4 2.0

1 62 21 4.6 ε

2 50 50 7.1 0.99

3 38 70 8.4 ε

4 35 67 8.2 ε

5 14 45 6.7 ε

6 20 22 4.7 0.61

7 20 8 2.9 ε

8 8 2 1.5 ε

9 6 1 0.7 ε

10 6 0 0.3 ε

11 6 0 0.1 ε

12 2 0 0.0 ε

13 1 0 0.0 ε

14 1 0 0.0 ε

15 0 0 0.0 1.00

16 0 0 0.0 1.00

The common security requirement categories

from the sources are presented next. For readability,

they are divided into product security requirements

and life-cycle requirements.

3.2 Product Security Requirements

Product requirements target the IoT device and the

supporting system. Table 3 shows the product se-

curity base categories and subcategories covered by

Common Cybersecurity Requirements in IoT Standards, Best Practices, and Guidelines

151

Table 3: Common product requirement categories. The table shows base categories, subcategories covered by at least 10

sources, the number of covering sources, and the proportion of subcategories from all categories. Subcategories are preﬁxed

by a dash. As a subcategory can be a speciﬁc category in many categories, the sum of proportions exceeds 100%.

Category Sources Prop. Category Sources Prop.

Security design 16 9.3% Security hardware 13 1.9%

– security architecture 16 8.9% – tamper protection 11 0.4%

– subsystems 10 2.2% Backend security 9 1.9%

– least privilege 15 1.5% Cryptography 13 5.9%

Secure programming 7 1.9% Data protection 16 14%

Delivery & deployment 14 4.8% – protect secrets 11 0.7%

– deployment integrity 14 4.5% – protection in transit 15 1.1%

– no global cred. 10 0.4% – comm. standards 13 0.4%

Administration 13 5.6% – decommission 11 0.7%

– secure conﬁg. 10 3.7% Service availability 12 2.2%

Interface security 16 9.3% Failure security 6 1.1%

– min. attack surface 13 4.8% Audit logging 11 1.9%

– no unused interfaces 11 0.4% Intrusion detection 15 5.2%

– validate input 10 1.1% – software integrity 11 0.7%

Authentication 16 13% Incident response 8 1.9%

– passwords 12 4.1% System updates 16 5.9%

– auth. brute force 10 0.4% – update security 14 0.4%

– component auth. 14 2.2% Usability of security 10 2.2%

Access control 10 2.6%

at least 10 sources, the number of covering sources,

and the proportion of subcategories from all cate-

gories. The categories covered by all sources are Se-

curity design, Interface security, Authentication, Data

protection, and System updates. The subcategories

of both Authentication and Data protection represent

over 10% share of all categories.

The next paragraphs explain the product require-

ment categories as described in the requirement

sources.

Security design considers the whole IoT system

holistically and includes the security architecture.

The system is made up of subsystems and their con-

nections. The design follows the security design prin-

ciples, such as the least privilege. Secure program-

ming practices are enforced as relevant for the used

languages, frameworks, compilers, etc. Delivery &

deployment of the system must be secure. The de-

ployment integrity requires the installation is not

tampered with, the environment meets security re-

quirements, and the system is hardened and secure

after the installation. There must be no global cre-

dentials, such as shared passwords. Administration

functions are protected, especially the remote admin-

istration interfaces. The secure conﬁguration of ac-

counts, roles, networks, and other critical settings is

ensured.

Interface security deﬂects attacks at the system

boundary, which often is the network interface. De-

fence is easier by minimizing the attack surface,

such as network ports and open services, and having

no unused interfaces. One should validate input

from untrusted sources to avoid disruption by mali-

cious input. Authentication by passwords or other

means establishes the identity of the users. Password

guessing and other authentication brute force at-

tacks are mitigated. Proper component authentica-

tion identiﬁes the components of the system. Access

control limits the actions available for users and com-

ponents. Security hardware provides security fea-

tures, such as cryptographic functions, memory iso-

lation, and trusted platform modules (TPMs). Equip-

ment located outside secure premises requires tam-

per protection. Backend security is an essential part

of IoT system security. Backend is often in a cloud

and there is a related web service, which must also

be secured. Cryptography should be based on estab-

lished standard algorithms. The used cryptographic

keys must be securely generated, stored, and updated.

Data protection must include all critical data, es-

pecially private information. The system must pro-

tect secrets such as keys and provide data protection

in transit over networks and other untrusted media,

preferably using secure communication standards.

Finally, the decommission of an IoT device includes

the destruction of critical data. Service availability

requirements are strict for critical infrastructure, e.g.

ICS systems, but all IoT devices must tolerate power

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

152

and network outages. Failure security means that if

the system fails due to internal or external reasons,

the system does not enter an insecure state or disclose

critical data.

Audit logging stores the important events for later

analysis. Intrusion detection system (IDS) moni-

tors the system for malicious activity. Unauthorized

software or ﬁrmware changes are detected to main-

tain the software integrity. An intrusion prevention

system (IPS) actively mitigates attacks, such as de-

nial of service (DOS) attacks. Incident response

should be supported by the system, e.g. by facilitat-

ing backup restore or providing means to check sys-

tem integrity. System updates are required for secu-

rity ﬁxes and enhancements after deployment while

maintaining update security to ensure that the ap-

plied updates are not compromised. Usability of se-

curity ensures administrators and users know how to

use the system securely, including instructions for de-

ployment and use. Security-critical decisions should

be avoided. Idle sessions should be locked or termi-

nated after a timeout.

It is notable and surprising that the category for

privacy was only covered by nine sources, thus it did

not make it into the common categories.

3.3 Life-cycle Security Requirements

Table 4 shows the common categories for IoT product

life-cycle security requirements. The most common

categories are Security requirements, Security stan-

dards and Vulnerability management covered by 14

sources. The next paragraphs explain the life-cycle

requirement categories as described in the sources.

Vendor security is required to produce and main-

tain secure products. The management and other per-

sonnel must know the best practices and be commit-

ted to follow them. Policies & laws, e.g. general

data protection requirements (GDPR), must be hon-

oured to avoid legal and contract issues. Develop-

ment process activities and tools support the produc-

tion of secure products. The external components

acquired through the supply chain must be carefully

managed. Testing must include security tests. Secu-

rity requirements are derived from customer needs

and risk analysis. Security standards relevant for

the product must be followed, e.g. the communica-

tion standards. Vulnerability management is about

collecting information on the relevant security vulner-

abilities and responding to it properly and promptly

on time, especially in case of publicly known vul-

nerabilities. User communication keeps users and

administrators informed about security threats, miti-

gations, updates, and other important events.

3.4 Coverage of the Security Categories

There are 25 base categories combining the product

and life-cycle security requirements. Table 5 gives the

coverage of the categories in the sources. A source

covers between 13 to 25 of the base categories, the

average is 19. The average number of subcategories

per source varies between 9.1 for Data protection and

1.3 for Failure security

To get a complementary view to the security re-

quirements, the requirements were assigned into the

NIST Cybersecurity Framework functions Identify,

Protect, Detect, Respond, and Recover (NIST, 2018).

Requirements are assigned into the function they sup-

port, e.g. category Data protection requirements for

function Protect. The result is shown in Table 6.

The requirements supporting Identify function are for

risk analysis, secure design, and management of the

supply chain. Protect is supported by requirements

for authentication, access-control, interface protec-

tion, data protection and management, etc. This func-

tion receives the majority of categories. Detect is sup-

ported by requirements for logging, tamper protec-

tion, and intrusion detection. Respond is supported

by requirements for vulnerability management and in-

cident response. Recovery is supported by require-

ments for backup restore and securing of the systems

after incidents. About 50 requirement categories for

vendor security, development process, and security

standards were not assignable to any framework func-

tions.

3.5 Comparison to Other Studies

We compared the requirements categories with some

other studies. Momenzadeh et al. collected 56 best

practices for security analysis of two consumer IoT

devices and covered 16 base categories (Momenzadeh

et al., 2020). The practices were divided into cate-

gories privacy and authentication, system operation,

device policies, vulnerability mitigation, and device

operation. Any best practices not observable from the

products were dropped, thus excluding vendor secu-

rity, backend security and secure programming. Stel-

lios et al. presented a set of ICS security controls

based on common attack patterns and risk analysis

and covered 13 base categories (Stellios et al., 2018).

The controls aim to reduce threat level, reduce vul-

nerability level, or reduce potential impact of con-

nectivity. The focus is also on the product security

requirements, although security testing is mentioned

from life-cycle requirements. Many of the require-

ments are for administration. There are no require-

ments for backend, cloud, web, secure programming,

Common Cybersecurity Requirements in IoT Standards, Best Practices, and Guidelines

153

Table 4: Common life-cycle requirement categories. The table shows base categories, subcategories covered by at least 10

sources, the number of covering sources, and the proportion of subcategories from all categories. Subcategories are preﬁxed

by a dash. A subcategory can be a speciﬁc category in many categories.

Category Sources Prop. Category Sources Prop.

Vendor security 8 3.7% Security standards 14 2.2%

Policies & laws 10 6.3% – comm. standards 13 0.4%

Development process 12 8.6% Vuln. management 14 3.7%

– ext. components 10 1.1% – known vuln. 10 0.7%

– security tests 10 4.1% User communication 12 1.9%

Security requirements 14 4.5%

– risk analysis 11 0.7%

Table 5: Coverage of the security base categories in the sources. For each base category, the table shows the total subcategory

count, count per source, and average count per source. The last row shows the number of covered base categories per source.

Cats.

(CSDE, 2019)

(CTIA, 2021)

(NCSC-FI, 2021)

(ENISA, 2017)

(ETSI, 2020)

(FDA, 2018)

(GSMA, 2018)

(ISASecure, 2019)

(IMDA, 2020)

(IS, 2017)

(IoTSI, 2018)

(IoTSF, 2020)

(IoTAC, 2016)

(NCSC-FI, 2019)

(NHTSA, 2020)

(NIST, 2020)

Avg.

Vendor security 10 3 2 2 2 3 3 5 5 3.1

Policies & laws 17 1 2 8 6 12 1 9 1 9 5 5.4

Development process 23 3 6 1 10 7 17 4 4 7 9 10 10 7.3

Security requirements 12 1 1 7 1 6 5 5 2 3 1 3 5 4 4 3.4

Security design 25 2 3 1 7 3 6 9 11 6 1 9 9 4 10 2 2 5.3

Security standards 6 2 2 1 3 1 2 3 2 2 2 5 3 1 2 2.2

Secure programming 5 1 1 2 3 1 1 3 1.7

Delivery & deployment 13 1 1 2 2 7 8 4 3 2 1 5 1 5 1 3.1

Administration 15 3 2 2 4 2 4 7 4 2 3 3 7 3 3.5

Interface security 25 2 1 4 9 6 5 10 12 9 2 7 15 1 11 5 1 6.2

Authentication 35 2 8 2 8 6 11 14 12 12 8 7 16 1 14 1 3 7.8

Access control 7 1 2 1 3 2 4 5 2 3 1 2.4

Security hardware 5 2 1 3 2 1 3 2 1 1 2 3 1 1 1.8

Backend security 5 3 2 4 1 3 2 4 3 1 2.6

Cryptography 16 3 1 7 4 2 8 5 8 1 3 13 6 1 4.8

Data protection 38 5 5 3 17 10 5 22 7 9 16 5 16 3 18 2 3 9.1

Service availability 6 1 1 3 2 3 3 1 1 1 3 1 1 1.8

Failure security 3 1 2 1 2 1 1 1.3

Audit logging 5 2 2 1 2 1 4 2 3 2 1 1 1.9

Intrusion detection 14 1 3 6 4 7 6 7 8 1 1 9 3 5 3 2 4.4

Incident response 5 1 3 1 2 2 1 3 1 1.8

Vuln. management 10 2 4 4 4 4 4 7 4 5 1 5 3 4 6 4.1

System updates 16 2 4 4 6 9 4 4 4 5 7 1 10 1 7 1 5 4.6

User communication 5 1 1 2 1 3 3 4 3 1 3 1 1 2.0

Usability of security 6 2 3 2 1 2 2 1 3 2 2 2.0

Coverage 16 15 13 23 19 20 25 23 22 21 18 23 16 23 15 13 19

or incident response. Tange et al. and Hansch et

al. researched the security requirements for industrial

IoT and both covered 16 base categories (Tange et al.,

2020; Hansch et al., 2019).

Overall the requirement counts in the studies are

comparable to the sources with a small number of re-

quirements. The number of covered categories is on

the low side. The studies are often vague on the de-

tails of the requirements, which makes categorization

challenging. It is hard to compare them with the other

sources.

4 DISCUSSION

We collected security requirements from 16 different

sources and divided them into 25 base categories and

244 subcategories. Based on the frequency of the cat-

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

154

Table 6: Assignment of requirements into NIST Cybersecurity Framework functions. For each function, the table shows the

requirement category count, count per source, and average count per source.

Cats.

(CSDE, 2019)

(CTIA, 2021)

(NCSC-FI, 2021)

(ENISA, 2017)

(ETSI, 2020)

(FDA, 2018)

(GSMA, 2018)

(ISASecure, 2019)

(IMDA, 2020)

(IS, 2017)

(IoTSI, 2018)

(IoTSF, 2020)

(IoTAC, 2016)

(NCSC-FI, 2019)

(NHTSA, 2020)

(NIST, 2020)

Avg.

IDENTIFY 61 5 5 4 23 11 15 29 20 11 14 11 24 9 22 8 3 13.4

PROTECT 163 19 27 17 54 43 43 75 63 53 38 29 74 17 68 17 15 40.8

DETECT 21 4 5 8 5 11 8 12 11 3 2 10 6 7 5 2 6.6

RESPOND 22 4 2 4 7 5 10 8 14 9 6 1 7 7 10 8 2 6.5

RECOVER 3 3 1 1 2 2 1.8

egories shared by the sources, the sources do agree on

common security requirements. The categories cov-

ered in all sources are Security design, Interface se-

curity, Authentication, Data protection, and System

updates. Intrusion detection was covered by all but

one source. The categories describe a well-designed

product with a secured interface, authentication of

users, protection of critical data, and mechanism for

security updates. Detection of intrusions only makes

sense if someone can react and perform incident re-

sponse, unlikely for consumer IoT. Unexpectedly, the

category privacy was not frequent enough to be a

common category. Perhaps the protection of private

data is included in general data protection or con-

sidered irrelevant for a domain like ICS. The most

common categories are product-related. The life-

cycle requirements may have been considered pro-

prietary to vendors or out of scope for IoT security

requirements. The top life-cycle categories are Se-

curity requirements, Security standards, and Vulnera-

bility management. The ﬁrst two support the design

and implementation of a secure product and the lat-

ter is essential for maintaining security through prod-

uct lifetime. The agreement on security requirements

may partly be caused by the source authors referenc-

ing other sources. However, the references appear to

be made selectively, thus contributing to the shared

knowledge.

The selection of categories and subcategories is a

judgement call. We tried to be faithful to how the

requirements were presented in the sources. Many

of the categories have a lot of subcategories, which

may reﬂect both complexity or disagreement among

the sources. Data protection has the most subcate-

gories, 38, and an average of nine subcategories per

source. Many categories are present only in one or a

few sources resulting in a long tail of odd security re-

quirements. The more requirements a source has, the

more unique categories it tends to introduce.

A total of 10 sources are for generic IoT and six

for speciﬁc domains. The common categories are

generic and applicable in all IoT domains. Categories

in the domain-speciﬁc sources do not appear to dif-

fer much from the generic sources. Based on this, the

need for domain-speciﬁc IoT requirements looks lim-

ited.

We also mapped the security requirements into

NIST Cybersecurity Framework. The majority of the

applicable requirements support the framework func-

tion Protect. There was some support for functions

Identify, Detect, and Respond, but only marginal for

Recovery. The security requirements are focused on

incident prevention rather than response.

5 CONCLUSIONS

In this study, the security requirements in 16 stan-

dards, guidelines and best practices were divided into

requirement categories. A set of common categories

was identiﬁed, with all sources covering Security de-

sign, Interface security, Authentication, Data protec-

tion, and Updates. The common categories are made

up of many subcategories and many different security

requirements. The majority of requirement categories

are only present in ﬁve or fewer sources and many are

unique to a single source. Thus, despite the shared

high-level categories, the selection of a requirement

source has a big impact to the individual requirements

an IoT project must fulﬁl. Adding new requirement

sources likely brings in many new requirements.

Consolidation of IoT security requirements seems

desirable and possible, as even while the sources dis-

agree on details, they are aligned in the high-level se-

curity targets.

ACKNOWLEDGEMENTS

This work is done in the SECREDAS project funded

by Horizon 2020 programme (grant agreement nr.

783119) and by Business Finland.

Common Cybersecurity Requirements in IoT Standards, Best Practices, and Guidelines

155

REFERENCES

CSDE (2019). The C2 Consensus on IoT Device Security

Baseline Capabilities. , Council to Secure the Digital

Economy.

CTIA (2021). Cybersecurity Certiﬁcation Program for IoT

Devices, Version 1.4. , CTIA Certiﬁcation.

ENISA (2017). Baseline Security Recommendations for

IoT in the context of Critical Information Infrastruc-

tures. , European Union Agency For Network And

Information Security.

ETSI (2020). Cyber Security for Consumer Internet of

Things: Baseline Requirements v2.1.1. ETSI EN 303

645, ETSI.

FDA (2018). Content of Premarket Submissions for Man-

agement of Cybersecurity in Medical Devices, Draft

Guidance for Industry and Food and Drug Adminis-

tration Staff. , US Food and Drug Adminisration.

GSMA (2018). GSMA IoT Security Assessment CLP.17,

Version 3.0. , GSM Association.

Hansch, G., Schneider, P., Fischer, K., and B

ottinger,

K. (2019). A uniﬁed architecture for industrial iot

security requirements in open platform communica-

tions. In 2019 24th IEEE International Conference

on Emerging Technologies and Factory Automation

(ETFA), pages 325–332.

IMDA (2020). (IoT) Cyber Security Guide, Version 1. ,

Singapore Info-communications Media Development

Authority.

IoTAC (2016). IoT Security Guidelines, ver. 1.0. , IoT

Acceleration Consortium, Japan.

IoTSF (2020). IoT Security Compliance Questionnaire. ,

IoT Security Foundation.

IoTSI (2018). IoT Security Design Best Practises. , IoT

Security Initiative.

IS (2017). IoT Security & Privacy Trust Framework v2.5. ,

The Internet Society.

ISASecure (2019). Component Security Assurance - ISAS-

ecure certiﬁcation scheme, Version 4.3. CSA-100,

ISA Security Compliance Institute.

Momenzadeh, B., Dougherty, H., Remmel, M., Myers,

S., and Camp, L. J. (2020). Best practices would

make things better in the IoT. IEEE Security Privacy,

18(4):38–47.

NCSC-FI (2019). Information security and data protection

requirements for social welfare and healthcare pro-

curements, v.1.0.6. , National Cyber Security Centre

Finland.

NCSC-FI (2021). The Finnish Cybersecurity Label. , Na-

tional Cyber Security Centre Finland.

NHTSA (2020). Cybersecurity Best Practices for the Safety

of Modern Vehicles, Draft 2020 Update. , US Na-

tional Highway Trafﬁc Safety Administration.

NIST (2018). Framework for Improving Critical Infrastruc-

ture Cybersecurity Version 1.1. , US National Insti-

tute of Standards and Technology.

NIST (2020). IoT Device Cybersecurity Capability Core

Baseline. NISTIR 8259A, US National Institute of

Standards and Technology.

Sayegh, E. (2021). Peloton breach reveals a coming iot data

winter. Forbes.

Stellios, I., Kotzanikolaou, P., Psarakis, M., Alcaraz, C.,

and Lopez, J. (2018). A survey of iot-enabled cyberat-

tacks: Assessing attack paths to critical infrastructures

and services. IEEE Communications Surveys Tutori-

als, 20(4):3453–3495.

Tange, K., De Donno, M., Fafoutis, X., and Dragoni, N.

(2020). A systematic survey of industrial internet of

things security: Requirements and fog computing op-

portunities. IEEE Communications Surveys Tutorials,

22(4):2489–2520.

IoTBDS 2022 - 7th International Conference on Internet of Things, Big Data and Security

156