PSA Certified: securite IoT pilotee par Arm

Auteur Hugues Orgitello Mis à jour le 27 mai 2026 ~16 min de lecture

Guide · PSA Certified

Lance en 2017 par Arm aux cotes de Brightsight, CAICT, Prove&Run, Riscure et TrustCB, PSA Certified s'est impose en quelques annees comme le referentiel de securite le plus visible cote silicium IoT, en particulier sur les architectures Arm Cortex-M et Cortex-A. Le programme combine un cadre d'architecture (Platform Security Architecture, le framework PSA) avec un schema de certification a trois niveaux d'assurance, decline jusqu'aux puces, aux modules, aux systemes d'exploitation, aux bibliotheques cryptographiques et aux produits finis. Ce guide expose l'historique du scheme, son architecture (PSA-RoT, PSA Crypto API, PSA Attestation), la progression Level 1 vers Level 3, la certification distincte des API fonctionnelles, l'articulation avec SESIP, Common Criteria, ETSI EN 303 645, NIST 8259A et le Cyber Resilience Act, et les pieges les plus frequents au moment de cadrer un programme.

Origine et gouvernance du scheme

Le contexte de creation de PSA Certified, en 2017, est celui d'une absence quasi totale de referentiel de securite portable pour les composants IoT bas de gamme. Common Criteria existait depuis 1999 (ISO/IEC 15408) mais son cout, ses delais et son orientation cartes a puce le rendaient impraticable pour un microcontroleur a quelques dollars. GlobalPlatform travaillait sur ce qui deviendrait SESIP. Arm, qui domine deja le marche des cores embarques, prend l'initiative d'agreger un consortium d'evaluateurs et d'editeurs autour d'une architecture de reference et d'un schema d'evaluation calibre pour le materiel IoT.

Six entites fondent le scheme:

• Arm, editeur de l'architecture et porteur du nom commercial.
• Brightsight (Pays-Bas), laboratoire d'evaluation Common Criteria historique sur les cartes a puce et les composants securises.
• CAICT (Chine), centre de recherche sur les TIC affilie au ministere chinois de l'industrie et des technologies de l'information.
• Prove&Run (France), editeur de noyaux securises et expert evaluation.
• Riscure (Pays-Bas), laboratoire specialise dans les attaques par canal auxiliaire et l'injection de fautes.
• TrustCB (Pays-Bas), organisme de certification accredite, qui delivre formellement les certificats au nom du scheme.

TrustCB joue un role central que beaucoup d'industriels comprennent tardivement: c'est le seul Certification Body officiel du programme. Les laboratoires d'evaluation realisent les essais, mais c'est TrustCB qui revoit les rapports et publie le certificat sur le portail psacertified.org. Cette separation entre evaluation et certification reprend la logique des schemes Common Criteria et SESIP, et garantit l'independance de la decision finale.

Le programme s'est elargi depuis 2017 a une vingtaine de laboratoires accredites repartis en Europe, Asie et Amerique du Nord. Les principaux fournisseurs de silicium Arm participent activement: NXP, STMicroelectronics, Nordic Semiconductor, Infineon, Renesas, Microchip, Silicon Labs, Texas Instruments. Cote logiciel, les Trusted Firmware-M et Trusted Firmware-A (projets Linaro) constituent les implementations de reference du PSA-RoT pour Cortex-M et Cortex-A respectivement.

Le framework PSA, architecture de reference

Avant de parler de certification, il est essentiel de distinguer le framework PSA (Platform Security Architecture) du programme PSA Certified. Le framework est un ensemble de documents publies par Arm, librement consultables, qui definissent:

• une architecture de reference pour un produit IoT, avec les notions de PSA-RoT (Root of Trust), Application RoT, partitions secure et non-secure;
• une famille d'API standardisees: PSA Crypto API, PSA Storage API (Internal Trusted Storage et Protected Storage), PSA Attestation API, PSA Firmware Update API;
• un modele de menaces generique pour les produits IoT, structurant l'analyse de risque;
• une methode d'analyse, dite PSA Threat Models and Security Analyses (TMSA), qui produit une analyse de menaces standardisee par classe de produit.

Le framework est neutre vis-a-vis de l'architecture materielle, meme s'il est ne dans l'ecosysteme Arm et s'aligne naturellement sur TrustZone-M (Cortex-M) et TrustZone-A (Cortex-A). Des implementations RISC-V existent et progressent, notamment via Trusted Firmware-M qui supporte plusieurs plateformes.

PSA Certified est le programme qui evalue la conformite d'une implementation a ce framework. La nuance est importante en pratique: un fabricant peut implementer PSA sans certifier (par exemple pour une premiere version d'un produit), mais il ne peut pas certifier sans avoir implemente le framework.

Le PSA-RoT et l'isolation secure / non-secure

Le PSA Root of Trust (PSA-RoT) est le concept central du framework. Il designe l'ensemble minimal de composants materiels et logiciels qui ancrent la chaine de confiance d'un produit:

• Hardware Unique Key (HUK), cle unique par puce stockee en zone non extractible;
• Initial Attestation Key (IAK), cle d'attestation utilisee pour signer les rapports d'integrite;
• Secure Boot, chaine de demarrage avec verification de signature a chaque etape;
• Secure Storage, stockage chiffre et integre pour les secrets;
• Crypto Services, services cryptographiques accessibles via PSA Crypto API;
• Attestation Service, generation des rapports d'attestation signes.

Le PSA-RoT s'execute en zone secure, isolee du reste de l'application (zone non-secure). Sur Cortex-M, cette isolation est typiquement assuree par TrustZone-M, qui partitionne la memoire, les peripheriques et les transitions d'execution entre les deux mondes. Sur Cortex-A, l'isolation passe par TrustZone-A combinee a un Trusted Execution Environment (TEE) tel que OP-TEE.

L'isolation correcte entre secure et non-secure est l'une des causes de non-conformite les plus frequentes au stade de l'evaluation Level 2. Une mauvaise configuration des Security Attribution Units (SAU) sur Cortex-M, un peripherique partage entre les deux zones sans mediation, un debordement de tampon traversant la frontiere: chacun de ces defauts invalide l'isolation et fait basculer un dossier en non-conformite.

Les trois niveaux de certification

PSA Certified definit trois niveaux d'assurance, conçus comme une progression. Le choix du niveau cible depend du modele de menace, du marche vise et du budget disponible.

Critere	Level 1	Level 2	Level 3
Nature	Gouvernance et bonnes pratiques	Evaluation laboratoire boite blanche	Evaluation laboratoire avec attaques substantielles
Methode	Questionnaire auto-evalue + entretien laboratoire	Tests sur PSA-RoT, attaques logicielles, canal auxiliaire et injection de fautes au niveau d'entree	Tests etendus, attaques renforcees, effort substantiel
Couverture	10 exigences (Secure Lifecycle, Identification, Updates, etc.)	PSA-RoT complet selon Protection Profile	PSA-RoT durci contre attaquant capable
Resistance attaquant	Non quantifiee	Attaquant basique a moyen	Attaquant moyen a substantiel
Effort fabricant	Quelques semaines de documentation	Plusieurs mois, retours d'analyse possibles	Plus long, depend de la maturite du composant
Alignement SESIP	Indicatif	SESIP3	SESIP4 et SESIP5
Reference externe	ETSI EN 303 645, NIST 8259A	Protection Profile PSA + cartographie SESIP	Protection Profile PSA renforce
Cible typique	Produit fini, OS, bibliotheque	Chip, module, OS securise	Composant securise haut de gamme

Level 1, gouvernance et bonnes pratiques

Level 1 est une auto-evaluation par le fabricant sur dix exigences couvrant la gouvernance et l'hygiene de securite: cycle de vie du produit, identification unique des dispositifs, mots de passe par defaut, divulgation de vulnerabilites, mises a jour securisees, stockage des secrets, isolation, communication, donnees personnelles, configuration par defaut. Le questionnaire est rempli par le fabricant puis revu par un laboratoire accredite via un entretien et une analyse documentaire (sans test en laboratoire au sens strict).

Le contenu de Level 1 est tres largement aligne sur ETSI EN 303 645 et sur NIST 8259A: les memes themes y figurent, parfois dans la meme formulation. Un fabricant ayant deja constitue un dossier 303 645 ou un dossier d'auto-evaluation NISTIR 8425 trouve l'essentiel des elements de reponse pour Level 1.

Le piege classique est l'idee qu'un Level 1 obtenu sur une plateforme suffit pour un produit final qui l'integre. Ce n'est pas le cas: l'evaluation est specifique a une combinaison materiel + firmware + version, et tout changement substantiel demande une mise a jour du certificat.

Level 2, evaluation laboratoire boite blanche

Level 2 introduit une evaluation laboratoire effective sur le PSA-RoT, conduite par un laboratoire accredite contre un Protection Profile publie par le scheme. L'evaluation est conduite en boite blanche: le fabricant fournit les sources, la documentation d'architecture, les schemas materiels et les masques pertinents. L'evaluateur teste:

• la conformite aux exigences du Protection Profile (architecture, services, API);
• la robustesse aux attaques logicielles au niveau d'entree (debordements, manipulation d'arguments, confusion de types);
• la robustesse aux attaques par canal auxiliaire au niveau d'entree (analyse de consommation, analyse d'emissions electromagnetiques) sur les operations cryptographiques sensibles;
• la robustesse a l'injection de fautes au niveau d'entree (perturbations d'horloge, glitches de tension) sur les chemins critiques.

L'expression "niveau d'entree" est essentielle: Level 2 ne pretend pas resister a un attaquant disposant de moyens substantiels. Il valide une resistance face a un attaquant disposant d'outils accessibles, mais sans equipement de laboratoire avance. Cette resistance est suffisante pour un nombre important de produits IoT grand public et industriels, mais elle ne convient pas pour des cibles a forte valeur attaquant (paiement, identite, infrastructures critiques).

Level 2 est aligne avec SESIP3 via une cartographie publiee par les deux schemes. Un produit certifie PSA Certified L2 peut, dans la plupart des cas, etre reconnu equivalent SESIP3 sans repasser une evaluation complete (sous reserve d'une revue de TrustCB).

Level 3, attaques substantielles et effort laboratoire

Level 3 etend Level 2 par un renforcement substantiel des attaques. Le laboratoire dispose d'un effort de test sensiblement superieur, calibre pour eprouver la resistance face a un attaquant capable. Les categories d'attaques sont les memes (logiciel, canal auxiliaire, injection de fautes) mais l'intensite et la creativite des tests sont accrues. Le scheme ne publie pas de bareme d'heures rigide: la duree depend du Protection Profile applique et de la complexite du composant.

Level 3 cible principalement des composants haut de gamme (secure elements integres, secure enclaves, microcontroleurs securises) destines a des applications a forte exigence: paiement, identite numerique, e-sante, certaines applications industrielles critiques. Pour ces cibles, Level 3 est aligne avec SESIP4 ou SESIP5, et il commence a recouper le territoire historique des Common Criteria EAL4+ a EAL5.

La PSA Functional API Certification

Distincte de la certification de plateforme, la PSA Functional API Certification valide la conformite d'une implementation logicielle aux API fonctionnelles publiees par Arm. Elle ne porte pas sur la securite globale d'un produit, mais sur le respect des signatures, codes d'erreur, et comportements specifies par les documents PSA API.

Dimension	PSA Functional API Certification	PSA Certified L1/L2/L3
Objet	Conformite a une API publiee (signatures, codes, comportement)	Securite de l'implementation et du produit
Cible typique	OS, bibliotheque cryptographique, Trusted Firmware, runtime	Chip, module, produit fini
API couvertes	Crypto, Storage (ITS et PS), Attestation, Firmware Update	Toutes, en plus de l'architecture et des essais
Tests	Suite de tests de conformite (PSA API Tests)	Analyse de menaces, tests d'attaque (L2/L3)
Independance	Independant des trois niveaux	Independant de la Functional API Cert
Implementation de reference	Mbed TLS pour la Crypto API	Trusted Firmware-M, Trusted Firmware-A

Une bibliotheque cryptographique peut etre Functional API certifiee sans qu'un produit la mettant en oeuvre soit lui-meme PSA Certified. Et a l'inverse, une puce certifiee PSA L2 ne fait pas automatiquement l'objet d'une Functional API Certification, qui necessite une demarche distincte. Cette separation evite la confusion classique entre conformite d'interface et conformite de securite.

La PSA Crypto API a, depuis 2020, ete adoptee comme l'interface cryptographique de Mbed TLS (devenu Mbed TLS Crypto puis fusionne avec PSA), ce qui en fait l'une des API cryptographiques les plus largement deployees dans l'IoT embarque, bien au-dela du seul ecosysteme PSA Certified.

PSA Attestation, la preuve d'identite et d'integrite

PSA Attestation est le service qui produit un rapport d'attestation signe par le PSA-RoT, attestant de l'identite materielle et de l'etat d'integrite du produit a un instant donne. Le rapport contient typiquement:

• l'identifiant unique du composant (Instance ID derive du HUK);
• le hash du firmware en cours d'execution;
• le niveau de certification PSA atteint (claim PSA Lifecycle);
• des claims metier specifiques au produit;
• la signature par l'Initial Attestation Key (IAK).

Ce rapport peut etre verifie par un service distant (cloud, plateforme de gestion de flotte) qui s'assure que le produit qu'il provisionne est bien celui qu'il pretend etre, et qu'il execute un firmware connu. PSA Attestation est utilisee en pratique pour le device onboarding (FDO, IoT Hub Microsoft, AWS IoT Core), la rotation de cles et la verification de mises a jour.

L'attestation est un service du PSA-RoT, donc protege en zone secure. Sa qualite depend directement de la qualite de l'isolation: une compromission du non-secure ne doit pas permettre de forger un rapport d'attestation.

PSA Certified Lite, pour les MCU contraints

PSA Certified Lite est une declinaison de Level 1 adaptee aux microcontroleurs a tres faibles ressources, ou la mise en oeuvre complete d'un PSA-RoT avec TrustZone-M n'est pas realiste. Le scheme adapte le questionnaire en tenant compte des contraintes materielles (absence d'unite d'isolation, memoire reduite), tout en preservant les controles de gouvernance: mises a jour, divulgation de vulnerabilites, support produit, identification.

Cette variante repond a un constat industriel: une part substantielle du parc IoT mondial s'appuie sur des MCU 8 ou 16 bits, ou sur des Cortex-M0+ sans MPU ni TrustZone-M. Imposer un PSA-RoT complet sur ces cibles serait irrealiste, mais leur reconnaitre une exemption complete reviendrait a creer une zone grise critique pour la securite de l'ecosysteme. Lite formalise un compromis.

PSA Certified, SESIP et Common Criteria

Les trois schemes coexistent et se chevauchent partiellement. Le tableau ci-dessous resume leur positionnement.

Dimension	PSA Certified	SESIP	Common Criteria (ISO/IEC 15408)
Editeur	Arm + consortium, TrustCB pour la certification	GlobalPlatform	ISO/IEC, schemes nationaux (ANSSI, BSI, NIAP, etc.)
Date de creation	2017	2020 (premiere version), revisions depuis	1999 (ISO 15408), origine 1990 (Orange Book, ITSEC, CTCPEC)
Cible	IoT embarque, Arm Cortex-M / Cortex-A	IoT et plateformes embarquees, multi-architecture	Tous produits TIC, focus historique cartes a puce et OS securises
Niveaux	3 niveaux + Functional API + Lite	5 niveaux (SESIP1 a SESIP5)	7 niveaux d'assurance (EAL1 a EAL7)
Modele d'assurance	Protection Profile dedie par niveau	Protection Profile et claims modulaires	Protection Profile et Security Target par produit
Reconnaissance internationale	Croissante, surtout dans l'ecosysteme Arm	Croissante, reconnaissance EU-CC en preparation	Etendue, reconnaissance CCRA pour EAL1 a EAL2 et SOG-IS pour les niveaux superieurs
Cout typique	Modere a substantiel selon le niveau	Modere a substantiel selon le niveau	Eleve, surtout au-dela d'EAL4+
Reconnaissance reglementaire	Indirecte (cartographies, citations)	Indirecte, croissante	Directe pour certains schemes nationaux (paiement, identite)

La logique pratique est la suivante: pour un produit IoT de masse sur Arm Cortex-M, PSA Certified L1 puis L2 est generalement le chemin le plus direct, avec une cartographie SESIP3 obtenue de facto. Pour un composant securise haut de gamme avec exigences reglementaires fortes (paiement, identite, eIDAS), Common Criteria reste la voie historique, eventuellement combinee a PSA Certified L3 ou SESIP4/5. Pour un produit multi-architecture (incluant RISC-V ou Arm), SESIP offre une portabilite legerement superieure.

Articulation avec ETSI EN 303 645, RED 3.3 et NIST 8259A

PSA Certified L1 reprend tres directement les exigences de gouvernance d'ETSI EN 303 645 et de NIST 8259A. Un fabricant ayant produit un dossier d'auto-evaluation 303 645 dispose deja de la majorite des reponses au questionnaire L1.

Cote regulation europeenne, la directive RED 3.3 entree en application le 1er aout 2025 impose la conformite a trois exigences essentielles (3.3(d) protection des reseaux, 3.3(e) protection des donnees personnelles, 3.3(f) protection contre la fraude) pour tout equipement radio connecte a internet. La voie formelle de presomption de conformite passe par la serie de normes harmonisees EN 18031, et non par PSA Certified. Un certificat PSA L1 ou L2 peut neanmoins etre cite dans le dossier technique au titre de l'article 3.3, en complement, ou comme element de demonstration de l'etat de l'art. Il n'ouvre pas a lui seul la presomption de conformite.

Cote Etats-Unis, NISTIR 8425 (Recommended Cybersecurity Requirements for Consumer-Grade Routers, 2022) et le US Cyber Trust Mark adoptent une logique de capacites de securite proche de celle de PSA L1. La encore, PSA Certified n'est pas la voie formelle vers le label, mais il en couvre une part substantielle des exigences.

Articulation avec le Cyber Resilience Act

Le Cyber Resilience Act, applicable a partir du 11 decembre 2027, etendra l'obligation de cybersecurite a tous les produits avec elements numeriques mis sur le marche europeen, qu'ils soient radio ou non. Les normes harmonisees du CRA sont en cours d'elaboration via le mandat de standardisation de la Commission europeenne aux organismes europeens de normalisation.

Plusieurs categories de produits seront classees importantes (Class I) ou critiques (Class II) avec des regimes d'evaluation tierce-partie obligatoires. Pour ces categories, PSA Certified L2 ou L3, ou un certificat SESIP equivalent, est susceptible d'etre reconnu comme moyen de preuve de conformite, sous reserve de la publication des normes harmonisees et des actes delegues correspondants. La cartographie precise reste a etablir.

A court terme, la position raisonnable est de ne pas considerer PSA Certified comme une voie alternative au CRA, mais comme un investissement durable dont une fraction substantielle pourra etre re-valorisee lorsque les normes CRA seront publiees.

Pieges frequents au cadrage

Confondre framework PSA et PSA Certified

Le piege le plus repandu cote ingenierie consiste a affirmer que le produit "implemente PSA" sans avoir engage de certification. C'est correct techniquement (le framework est librement implementable), mais incorrect commercialement: aucun logo PSA Certified ne peut etre utilise, et aucune cartographie SESIP n'est applicable. Le marketing doit respecter cette distinction.

Confondre PSA Functional API Certification et certification de plateforme

Un fournisseur de bibliotheque cryptographique communique parfois sur sa Functional API Certification (Mbed TLS, par exemple) en laissant entendre que les produits qui l'integrent sont securises au sens PSA. Ce n'est pas le cas: la Functional API Certification valide une interface logicielle, pas une architecture de securite. Un produit integrant une bibliotheque Functional API certifiee peut etre completement insecure si son architecture, son isolation et son cycle de vie sont defaillants.

Demander L1 quand l'acheteur attend L2

Sur les marches grand public, certains donneurs d'ordre (chaines de distribution, integrateurs smart home) ont commence a exiger PSA Certified L2 dans leurs cahiers des charges, en particulier pour les composants exposes (passerelles, hubs, cameras). Presenter un L1 quand un L2 est attendu fait perdre des contrats. La verification du niveau attendu en amont de la roadmap produit est essentielle.

Negliger l'isolation secure / non-secure

L'isolation entre PSA-RoT (secure) et application (non-secure) est l'objet le plus eprouve lors d'une evaluation L2. Une configuration SAU mal posee sur Cortex-M, un peripherique partage sans mediation, une variable globale traversant la frontiere: chacun de ces defauts est detecte en laboratoire et invalide l'evaluation. L'audit interne de l'isolation, avec un outillage adapte (Trusted Firmware-M de reference), doit etre realise avant l'entree en laboratoire.

Sous-estimer les iterations laboratoire

Une evaluation L2 sans rapport interne prealable produit souvent plusieurs cycles d'analyse, avec corrections firmware ou materielles entre chaque iteration. Le calendrier doit prevoir ces iterations: viser L2 en six semaines calendaires sans pre-evaluation interne est generalement irrealiste.

Croire que L2 dispense d'une revue cryptographique

Level 2 valide l'implementation correcte des services cryptographiques au sens du Protection Profile, mais il ne couvre pas exhaustivement la qualite des protocoles applicatifs construits par-dessus. Une revue cryptographique du protocole metier (typiquement TLS, MQTT-S, LwM2M-DTLS, protocoles proprietaires) reste necessaire en complement.

Confondre PSA Lite et PSA L1

PSA Certified Lite n'est pas un sous-ensemble de L1, c'est un programme adjacent destine aux composants pour lesquels L1 ne peut pas s'appliquer fidelement. Le presenter comme un L1 affaibli expose a une perte de credibilite vis-a-vis d'un acheteur informe.

Pour un fabricant: cadrer la demarche

Voir aussi

• SESIP: methodologie d'evaluation cybersecurite IoT
• TPM 2.0 et securite materielle TCG
• Common Criteria (ISO/IEC 15408) : securite IT
• ETSI EN 303 645 : cybersécurité IoT consommateur
• CRA : Cyber Resilience Act, exigences UE numerique
• IEC 62443 (ISA-99), cybersecurite des systemes industriels

Un cas concret de cadrage d'un programme PSA Certified ? AESTECHNO peut auditer votre conception et votre plan de certification. Nous contacter →

Trois etapes structurent un cadrage serieux:

1. Determiner le niveau cible. Modele de menace, marche vise, exigences contractuelles des donneurs d'ordre, anticipation reglementaire (RED 3.3, CRA). Cette analyse doit produire une cible explicite: L1, L2, L3, Lite, ou Functional API. Vise-t-on aussi une cartographie SESIP ? Une cartographie avec un label national (par exemple le label Traficom, le UK PSTI Act, le Singapore CLS) ?
2. Selectionner la plateforme silicium et le firmware de reference. PSA Certified L2 et L3 sont realistes sur une puce dont le silicium est lui-meme certifie (typiquement un Arm SecurCore ou un MCU avec TrustZone-M actif), et sur un firmware Trusted Firmware-M de reference ou un derive maintenu. Demarrer L2 sur une plateforme sans support du PSA-RoT est generalement contre-productif.
3. Pre-evaluation interne avant entree en laboratoire. Tests d'isolation, revue de l'analyse de menaces TMSA, verification de la conformite aux API. Cette phase reduit substantiellement la duree de l'evaluation laboratoire et le nombre d'iterations.

Pour la dimension reglementaire europeenne (RED 3.3, CRA, EN 18031), voir le pillier RED qui detaille les voies de presomption de conformite et leur articulation avec les schemes de certification volontaires comme PSA.

Besoin d’un appui ?

Un audit de 30 minutes avec les ingénieurs AESTECHNO.

AESTECHNO est le bureau d'études qui édite spilma. Nous aidons les équipes produit à cadrer leur démarche de certification et à éviter les pièges classiques.

Réserver un audit gratuit

Pour aller plus loin

• ETSI EN 303 645: cybersecurite IoT consommateur, base de PSA Certified L1
• Cyber Resilience Act: regulation europeenne applicable a partir de decembre 2027
• Pillier RED: cadre general radio europeen et article 3.3
• Glossaire: definitions des termes PSA-RoT, TrustZone, attestation, SESIP

Sources & références

1. PSA Certified, portail officiel du programme de certification , PSA Certified www.psacertified.org/
2. PSA Certified, niveaux de certification (Level 1, 2, 3) , PSA Certified www.psacertified.org/certification/
3. Arm Platform Security Architecture, architectures de reference , Arm developer.arm.com/architectures/security-architectures/platform-security-architecture
4. GlobalPlatform SESIP, methodologie d'evaluation pour plateformes IoT , GlobalPlatform globalplatform.org/sesip/
5. NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline , NIST csrc.nist.gov/publications/detail/nistir/8259a/final
6. NIST IR 8425, Recommended Cybersecurity Requirements for Consumer-Grade Routers , NIST csrc.nist.gov/publications/detail/nistir/8425/final
7. ETSI EN 303 645 V3.1.3, cybersecurity for consumer IoT , ETSI www.etsi.org/deliver/etsi_en/303600_303699/303645/