prEN 17927

SLOVENSKI STANDARD
oSIST prEN 17927:2023
01-februar-2023
Standard ocenjevanja varnosti za platforme IoT (SESIP) - Učinkovita metodologija
za uporabo ocene kibernetske varnosti in ponovno uporabo za povezane izdelke

Security Evaluation Standard for IoT Platforms (SESIP) - An effective methodology for

méthodologie efficace pour appliquer l'évaluation de la cybersécurité et la réutilisation

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

Norme d'évaluation de la sécurité pour les plates- Sicherheitsbewertungsstandard für IoT-Plattformen -

formes IoT (SESIP) - Une méthodologie efficace pour Eine effektive Methode zur Anwendung der

appliquer l'évaluation de la cybersécurité et la Cybersicherheitsbewertung und Wiederverwendung

This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee

If this draft becomes a European Standard, CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal

Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any

This draft European Standard was established by CEN and CENELEC in three official versions (English, French, German). A

version in any other language made by translation under the responsibility of a CEN and CENELEC member into its own language

and notified to the CEN-CENELEC Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,

Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,

Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are

aware and to provide supporting documentation.Recipients of this draft are invited to submit, with their comments, notification

of any relevant patent rights of which they are aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without

European foreword ............................................................................................................................................ 3

Introduction .......................................................................................................................................................... 4

1 Scope .......................................................................................................................................................... 5

2 Normative references .......................................................................................................................... 5

3 Terms, definitions, symbols and abbreviated terms ............................................................... 5

4 Overview .................................................................................................................................................. 6

5 Security Functional Requirements (SFRs) ................................................................................. 19

6 Security Process Packages (SPPs) ................................................................................................. 38

7 Security Assurance Requirements (SARs) ................................................................................. 40

8 SESIP Assurance Levels ..................................................................................................................... 53

Annex A (informative) SESIP evaluation case example ...................................................................... 60

Annex B (informative) Guidance — Attack potential rating ............................................................ 61

Annex C (informative) Example use cases .............................................................................................. 64

Annex D (informative) Security Target template ................................................................................. 73

Annex E (Normative) Composition Guidelines ...................................................................................... 92

Annex F (Informative) SESIP in overall product securing process ................................................ 98

Bibliography .................................................................................................................................................... 101

This document (prEN 17927:2022) has been prepared by Technical Committee CEN/JTC 13

This document specifies the Security Evaluation for Secure IoT Platforms (SESIP). It includes general

requirements for Security Functional Requirements (SFRs), Security Process Packages (SPPs) and

Security Assurance Requirements (SARs) designed to be used in the evaluation and certification of IoT

SESIP is a methodology for the security evaluation of platform on which of connected products are based.

The term “platform” in SESIP is defined as the implementation of underlying features for an application

SESIP does not address the final connected product itself, but the results of the SESIP evaluation of

connected platform are meant to be able to be used as evidence for compliance demonstration to

This make SESIP not redundant with current IoT standards but a tool on which those standards can base

on by reusing outputs. It is indeed impossible for a product vendor to provide, with reasonable effort,

assessment evidences for all platform parts integrated from different developers/manufacturers.

• To consider time-to-market needs by providing an optimized and efficient methodology;

• To enable the reuse of evaluation results in different products and/or between different standards

• To support Connected Products compliance demonstration to Connected Product standards.

Fulfilling of these goals allows SESIP raising the overall security in IoT ecosystems by increasing the

number of security evaluations through clarity in security claims and optimized efforts.

This document describes a cybersecurity evaluation methodology, named SESIP, for platforms and

platform parts of connected IoT products. Security claims in SESIP are made based on the security

services offered by those platforms. Platform parts can be in hardware and software. SESIP aims to

support comparability between and reuse of independent security evaluations. SESIP provides a common

set of requirements for the security functionality of platform parts which apply to the foundational

platforms of devices that are not application specific. The methodology describes the re-use of evaluation

The following documents are referred to in the text in such a way that some or all of their content

constitutes requirements of this document. For dated references, only the edition cited applies. For

undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 17065:2012, Conformity assessment — Requirements for bodies certifying products, processes and

For the purposes of this document, the terms and definitions given in ISO/IEC 17000:2020,

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

overall software layer implementing an IoT end-user use case based on the underlying connected

subset of the connected application defined by a specific context (e.g. data, resources, etc.) and to be

hardware and/or software that provides secure services to a connected application

developers who build platform (parts) and supply them to product vendors or to other platform

developers, and who need to certify the security of the platform (parts) that they build.

hardware and/or software that implements a subset of the features of a connected platform, and that can

combination of a connected platform and a connected application that a product vendor puts on the

security profile generic to a type of platform (part), template for a SESIP Security Target of a platform of

statement of SESIP security requirements in terms of security features (SFRs and SPPs) and evaluation

• Reusability, an essential objective of SESIP, in order to handle at an acceptable cost the increasing

complexity of the connected platforms that need to be evaluated in the IoT ecosystem

• Accessibility, which is required to encourage product vendors to leverage security features included

in evaluated connected platforms; the results of an evaluation is expected be accessible and

exploitable by security-proficient developers without the need to be evaluation specialists.

SESIP is originated from the ISO 15408 series ([4], [5], [6]), specialized for the evaluation of connected

• SESIP keeps the main definitions and high-level concepts introduced in ISO 15408-1 [4].

• SESIP Security Functional Requirements (SFRs) for the security features to be implemented by

platforms (parts) and to be evaluated; SESIP does not use the SFR catalogue defined in ISO 15408-2

[5] but keeps the concept of a catalogue of SFRs, specialized for the IoT ecosystem, but each SFR being

• SESIP Secure Process Packages (SPPs) for the security processes to be implemented by the developer

• SESIP Security Assurance Requirements (SARs) for the evaluation activities to be performed; SESIP

keeps the categorization of the Security Assurance Requirements and the associated type of

developer’s inputs as in ISO 15408-3 [6], however it redefines the content as described in 7.1.

• SESIP assurance levels; SESIP does not use “EAL” packages defined in ISO 15408-3 [6], but defines

its own assurance packages adapted to the IoT ecosystem: the SESIP levels (see Clause 8).

SESIP is an evaluation methodology that defines as precisely as possible how to evaluate the security of

a product, in this case a connected platform. Similarly, SESIP does not define any specific procedure, nor

does it explicitly organize the mutual recognition principles between certificates, and only provides

guidance and directions. A SESIP evaluation/certification scheme based on this SESIP evaluation

methodology is expected to be defined in another document by the certification scheme owner.

IoT is a broad term, but always contains a product (“thing”) and some form of connectivity (“internet”).

SESIP focuses on the “thing” side of IoT, and on the security of connected platforms, on which Connected

• Hardware (processing unit, memory, possibly a secure element, at least one network interface,

possibly some sensors) and associated features e.g. Firmware, Boot Loader and Root-of-Trust.

o It is assumed that the connected platform includes at least one network interface that is directly or

• An operating system, providing a foundation to run Connected Applications on the hardware.

• A network connectivity layer (e.g. Comm library), allowing the connection of the product to backend

• Software application services offered to Connected Applications, providing an application

framework to product vendors (e.g. Crypto library, Secure Storage, Identity and Attestation features).

Platform assets depend on the platform implementation and use case. However, the list of typical main

Data in transit (internet) Confidentiality and integrity are often essential, as is the

Code, including platform code and Integrity and authenticity are strong requirements.

It is understood that not all platforms provide complete coverage, but such limitations shall be carefully

The assets may be further categorized into different criticality levels that will be protected at the

appropriate level in the platform (part) – in the case of a multi-assurance platform, see 4.5.2. For instance,

there may be different levels of cryptographic keys, depending on their function and life cycle. In that

• Usage of the assets from a lower level shall be appropriately controlled (access control).

The minimum and mandatory threat model in SESIP is an attacker with only remote (no physical) access

to the connected platform during the exploitation phase (see Annex B). This addresses the main IoT

concern of a scalable attack exploited using a remote connection to the connected platform.

Nevertheless, the attacker can perform any type of preliminary attack on a connected platform (part)

owned, including physical attacks; this shall be considered for the base scenario in an identification phase

Also, in this base scenario, threats related to untrusted software that could be loaded onto connected

When connected platforms are physically accessible to attackers, the threat model can be expanded and

covered by the use of the SFRs “Limited physical attacker resistance” and “Physical attacker resistance”.

The typical example scenarios where attackers have physical access to a victim product are:

• Connected platform deployed outside of a physically protected environment; e.g. a doorbell, outside

• Temporary physical access; e.g. “evil maid” attacks where the attacker has temporary physical access

to the product that has already been acquired by an end user, or “supply chain” attacks where the

When untrusted software can be loaded onto connected platforms, either by the end user or by an

external entity, and that could impact the platform, its parts, or its applications, the base threat model can

be expanded and covered by the use of the SFRs “Software attacker resistance: Isolation of platform”,

“Software attacker resistance: Isolation of platform parts”, and “Software attacker resistance: Isolation of

Different life cycle models can be applied to Connected Products, and to the connected platforms that

compose each product. Nevertheless, some patterns can be found in most products that are significant

Vendor provisioning is the phase during which the product is provisioned with credentials that are

shared with the vendor’s backend, and that allow the product to communicate securely with the backend

and to perform management operations. This phase typically concludes with the delivery of the product

User provisioning is the phase during which the product is provisioned with a user’s credentials and

specific data that allow the product to represent that user. This phase typically concludes with the normal

Normal usage is supposed to be the product’s normal state, until one of the following events occurs:

• The user applies a factory reset, which removes all user-related data and credentials, and prepares

the product to be transferred to another entity (e.g. for resale, for return, or even for temporary

storage). The product is then ready again for user provisioning, but a user should not have the ability

• The user decommissions the product, before discarding it. This Terminated state is irreversible.

Some products may include an additional state related to Field return, during which specific debugging

features may be available. All user data and credentials shall have been removed before reaching that

The product life cycle shown in Figure 4-2 is used as a reference in the SFRs when references to a life

Note that the vendor states are only reachable by the vendor, either before delivery of the product, or

In addition to the product life cycle, the connected platform and some of its parts may have different life

cycles that are also significant to security. Such security life cycles are product-specific, and their

contribution to the security of the connected platform (part) should be described in the corresponding

Connected Products are complex, often much more than most of the products that have had their security

formally certified until today. SESIP recognizes this by providing a dedicated methodology for the

connected platforms on which these products are based. connected platforms are often built by

assembling several pre-existing hardware and software components; some of them include security

components that protect critical assets and need to be evaluated at a high assurance level. Such

components are often integrated in several connected platforms targeting different use cases.

SESIP methodology defines ways to independently evaluate subsets of components, which may then be

called platform parts, and reuse the evaluation results in any connected platform. Those results can come

from an evaluation under SESIP methodology, but also from other compatible external evaluations.

As mentioned in 4.3, SESIP focuses on the “Things” in IoT, and more specifically on the solutions on which

these connected things are built, which we call Connected Products. Every Connected Product belongs to

a category or a vertical, and dedicated security standards are likely to be built for the most common types

of Connected Products (e.g. Consumer IoT, Industrial IoT, Connected Vehicles, etc.). For each type, a

specific risk analysis is needed to determine the appropriate functional and assurance requirements and

In such a multi-scheme context, the SESIP methodology security requirements are defined in a way that

enables the establishment of equivalence with the requirements of other schemes. After successful

compatibility analysis, this allows the reuse of evaluation results between schemes.

A typical connected platform is not a monolithic component, as it comprises some hardware, including at

least one [micro]controller or [micro]processor, and some software, including at least an operating

system. A connected platform may include many more components, for instance related to

communication or security. A vendor typically builds its connected platform by selecting hardware and

software components, most likely from different third-party vendors, and then assembling them.

Every vendor in that supply chain needs to provide security evaluation assessment, ending with the

integrator in charge of ensuring that the full connected platform is secure. To maintain security through

the whole assembly process can be quite complex, unless all the vendors of those components (hardware

• Reuse of evaluated platform parts from a hosting platform (part) to another one

SESIP allows the evaluation of platform parts, individually or in composition (see 4.5.3), in such a way

that the evaluation results of those platform parts remain applicable in different Connected Products.

4.5.2.2.3 Reuse of evaluated platform parts from a hosting platform (part) to another one

Another case of reuse allowed by SESIP: When a part has been evaluated inside a particular platform

(part), the related evaluation results can be reused for integration into another platform (part).

Figure 4-4 — Example of evaluation results reuse from a platform (part) to another one

In all cases, the reuse of evaluation evidences is in particular based on security integration guidance for

each component; then, the assessment of the connected platforms integrating evaluated platform parts

requires the verification that secure integration guidelines and composition rules (see 4.5.2) are

Note that reuse effort will vary depending on the use case, from straightforward portability with few

verifications, e.g. full self-containment of security functionality, to a dedicated set of activities needing to

be performed on the integrating scope and to be defined in the previously mentioned integration and

composition guidelines. In any case, the effort will be significantly lower than a re-evaluation on

Using SESIP as core methodology allows vendors to have a clear understanding of the assumptions and

guidance of the third-party components they integrate by reusing evidences provided by the components’

Most Connected Products will be built by vendors who develop one or several dedicated Application(s)

on top of a generic or off-the-shelf connected platform. SESIP focuses on the connected platform to

provide a foundation for the security assessment, and potentially the certification, of Connected Products.

It addresses the security level of the whole operating system including services used for the storage,

installation, initialization, and execution of this Application, as well as its data protection.

The objective of additive composition is to facilitate the evaluation of a connected platform by reusing

• Combination of platform part(s) to be evaluated with previously evaluated platform part(s)

• Combination of a platform to be evaluated with previously evaluated platform parts

Additive composition allows successive compositions of platform parts into wider ones which themselves

can be evaluated and integrated into wider platform parts, as illustrated in Figure 4-5. Each composition

benefits from the reuse of the evaluation results of the previously integrated platform part. Such

integrations and related composition evaluation can be done until reaching a full IoT platform, ready to

be part of an IoT device. The final IoT device can rely on the successive evaluated platform parts and

reuse each evaluation result. All the supply chain actors benefit from the additive composition: from the

evaluation of a hardware block, through the evaluation of intermediate modules, to an evaluated device.