PSA Certified: sécurité IoT pilotée par Arm

Auteur Hugues Orgitello Mis à jour le 3 juillet 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 années comme le référentiel de sécurité 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 schéma de certification a trois niveaux d'assurance, decline jusqu'aux puces, aux modules, aux systèmes d'exploitation, aux bibliothèques cryptographiques et aux produits finis. Ce guide expose l'historique du schème, 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 fréquents au moment de cadrer un programme.

Origine et gouvernance du schème

Le contexte de création de PSA Certified, en 2017, est celui d'une absence quasi totale de référentiel de sécurité portable pour les composants IoT bas de gamme. Common Criteria existait depuis 1999 (ISO/IEC 15408) mais son coût, ses délais et son orientation cartes a puce le rendaient impraticable pour un microcontrôleur a quelques dollars. GlobalPlatform travaillait sur ce qui deviendrait SESIP. Arm, qui domine déjà le marche des cores embarques, prend l'initiative d'agréger un consortium d'évaluateurs et d'éditeurs autour d'une architecture de reference et d'un schéma d'évaluation calibre pour le matériel IoT.

Six entités fondent le schème:

• Arm, éditeur de l'architecture et porteur du nom commercial.
• Brightsight (Pays-Bas), laboratoire d'évaluation Common Criteria historique sur les cartes a puce et les composants securises.
• CAICT (Chine), centre de recherche sur les TIC affilie au ministère chinois de l'industrie et des technologies de l'information.
• Prove&Run (France), éditeur de noyaux securises et expert évaluation.
• 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 schème.

TrustCB joue un rôle central que beaucoup d'industriels comprennent tardivement: c'est le seul Certification Body officiel du programme. Les laboratoires d'évaluation réalisent les essais, mais c'est TrustCB qui revoit les rapports et publie le certificat sur le portail psacertified.org. Cette séparation entre évaluation et certification reprend la logique des schèmes Common Criteria et SESIP, et garantit l'indépendance de la décision finale.

Le programme s'est élargi 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 implémentations 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 définissent:

• 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 standardisées: PSA Crypto API, PSA Storage API (Internal Trusted Storage et Protected Storage), PSA Attestation API, PSA Firmware Update API;
• un modele de menaces générique pour les produits IoT, structurant l'analyse de risque;
• une méthode d'analyse, dite PSA Threat Models and Security Analyses (TMSA), qui produit une analyse de menaces standardisée par classe de produit.

Le framework est neutre vis-a-vis de l'architecture matérielle, même s'il est ne dans l'écosystème Arm et s'aligne naturellement sur TrustZone-M (Cortex-M) et TrustZone-A (Cortex-A). Des implémentations RISC-V existent et progressent, notamment via Trusted Firmware-M qui supporte plusieurs plateformes.

PSA Certified est le programme qui evalue la conformité d'une implémentation a ce framework. La nuance est importante en pratique: un fabricant peut implémenter PSA sans certifier (par exemple pour une première 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 matériels et logiciels qui ancrent la chaine de confiance d'un produit:

• Hardware Unique Key (HUK), cle unique par puce stockée en zone non extractible;
• Initial Attestation Key (IAK), cle d'attestation utilisée pour signer les rapports d'intégrité;
• Secure Boot, chaine de démarrage avec verification de signature a chaque étape;
• Secure Storage, stockage chiffre et integre pour les secrets;
• Crypto Services, services cryptographiques accessibles via PSA Crypto API;
• Attestation Service, génération des rapports d'attestation signes.

Le PSA-RoT s'execute en zone secure, isolée du reste de l'application (zone non-secure). Sur Cortex-M, cette isolation est typiquement assurée par TrustZone-M, qui partitionne la mémoire, les périphériques et les transitions d'exécution entre les deux mondes. Sur Cortex-A, l'isolation passe par TrustZone-A combinée 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-conformité les plus frequentes au stade de l'évaluation Level 2. Une mauvaise configuration des Security Attribution Units (SAU) sur Cortex-M, un périphérique partage entre les deux zones sans médiation, un débordement de tampon traversant la frontière: chacun de ces défauts invalide l'isolation et fait basculer un dossier en non-conformité.

Les trois niveaux de certification

PSA Certified définit trois niveaux d'assurance, conçus comme une progression. Le choix du niveau cible dépend 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'entrée	Tests étendus, attaques renforcées, 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 quantifiée	Attaquant basique a moyen	Attaquant moyen a substantiel
Effort fabricant	Quelques semaines de documentation	Plusieurs mois, retours d'analyse possibles	Plus long, dépend de la maturité 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, bibliothèque	Chip, module, OS securise	Composant securise haut de gamme

Level 1, gouvernance et bonnes pratiques

Level 1 est une auto-évaluation par le fabricant sur dix exigences couvrant la gouvernance et l'hygiène de sécurité: cycle de vie du produit, identification unique des dispositifs, mots de passe par défaut, divulgation de vulnérabilités, mises a jour sécurisées, stockage des secrets, isolation, communication, données personnelles, configuration par défaut. 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 très largement aligne sur ETSI EN 303 645 et sur NIST 8259A: les mêmes thèmes y figurent, parfois dans la même formulation. Un fabricant ayant déjà constitue un dossier 303 645 ou un dossier d'auto-évaluation NISTIR 8425 trouve l'essentiel des éléments de réponse pour Level 1.

Le piege classique est l'idée qu'un Level 1 obtenu sur une plateforme suffit pour un produit final qui l'integre. Ce n'est pas le cas: l'évaluation est spécifique a une combinaison matériel + firmware + version, et tout changement substantiel demande une mise a jour du certificat.

Level 2, évaluation laboratoire boite blanche

Level 2 introduit une évaluation laboratoire effective sur le PSA-RoT, conduite par un laboratoire accredite contre un Protection Profile publie par le schème. L'évaluation est conduite en boite blanche: le fabricant fournit les sources, la documentation d'architecture, les schémas matériels et les masques pertinents. L'évaluateur teste:

• la conformité aux exigences du Protection Profile (architecture, services, API);
• la robustesse aux attaques logicielles au niveau d'entrée (débordements, manipulation d'arguments, confusion de types);
• la robustesse aux attaques par canal auxiliaire au niveau d'entrée (analyse de consommation, analyse d'émissions électromagnétiques) sur les opérations cryptographiques sensibles;
• la robustesse a l'injection de fautes au niveau d'entrée (perturbations d'horloge, glitches de tension) sur les chemins critiques.

L'expression "niveau d'entrée" est essentielle: Level 2 ne prétend pas résister a un attaquant disposant de moyens substantiels. Il valide une résistance face a un attaquant disposant d'outils accessibles, mais sans équipement de laboratoire avance. Cette résistance 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, identité, infrastructures critiques).

Level 2 est aligne avec SESIP3 via une cartographie publiée par les deux schèmes. Un produit certifie PSA Certified L2 peut, dans la plupart des cas, être reconnu équivalent SESIP3 sans repasser une évaluation complete (sous reserve d'une revue de TrustCB).

Level 3, attaques substantielles et effort laboratoire

Level 3 étend Level 2 par un renforcement substantiel des attaques. Le laboratoire dispose d'un effort de test sensiblement supérieur, calibre pour éprouver la résistance face a un attaquant capable. Les catégories d'attaques sont les mêmes (logiciel, canal auxiliaire, injection de fautes) mais l'intensité et la créativité des tests sont accrues. Le schème ne publie pas de barème d'heures rigide: la durée dépend du Protection Profile applique et de la complexité du composant.

Level 3 cible principalement des composants haut de gamme (secure éléments integres, secure enclaves, microcontrôleurs securises) destines a des applications a forte exigence: paiement, identité numérique, 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 conformité d'une implémentation logicielle aux API fonctionnelles publiées par Arm. Elle ne porte pas sur la sécurité 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 publiée (signatures, codes, comportement)	Securite de l'implémentation et du produit
Cible typique	OS, bibliothèque 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 conformité (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 bibliothèque cryptographique peut être Functional API certifiée sans qu'un produit la mettant en oeuvre soit lui-même PSA Certified. Et a l'inverse, une puce certifiée PSA L2 ne fait pas automatiquement l'objet d'une Functional API Certification, qui necessite une demarche distincte. Cette séparation evite la confusion classique entre conformité d'interface et conformité de sécurité.

La PSA Crypto API a, depuis 2020, ete adoptée 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 déployées dans l'IoT embarque, bien au-dela du seul écosystème PSA Certified.

PSA Attestation, la preuve d'identité et d'intégrité

PSA Attestation est le service qui produit un rapport d'attestation signe par le PSA-RoT, attestant de l'identité matérielle et de l'état d'intégrité 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'exécution;
• le niveau de certification PSA atteint (claim PSA Lifecycle);
• des claims métier spécifiques au produit;
• la signature par l'Initial Attestation Key (IAK).

Ce rapport peut être 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 prétend être, et qu'il execute un firmware connu. PSA Attestation est utilisée en pratique pour le device onboarding (FDO, IoT Hub Microsoft, AWS IoT Core), la rotation de clés et la verification de mises a jour.

L'attestation est un service du PSA-RoT, donc protege en zone secure. Sa qualité dépend directement de la qualité 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 déclinaison de Level 1 adaptée aux microcontrôleurs a très faibles ressources, ou la mise en oeuvre complete d'un PSA-RoT avec TrustZone-M n'est pas realiste. Le schème adapte le questionnaire en tenant compte des contraintes matérielles (absence d'unité d'isolation, mémoire réduite), tout en préservant les controles de gouvernance: mises a jour, divulgation de vulnérabilités, support produit, identification.

Cette variante répond 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 irréaliste, mais leur reconnaître une exemption complete reviendrait a créer une zone grise critique pour la sécurité de l'écosystème. Lite formalise un compromis.

PSA Certified, SESIP et Common Criteria

Les trois schèmes 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, schèmes nationaux (ANSSI, BSI, NIAP, etc.)
Date de création	2017	2020 (première version), révisions depuis	1999 (ISO 15408), origine 1990 (Orange Book, ITSEC, CTCPEC)
Cible	IoT embarque, Arm Cortex-M / Cortex-A	IoT et plateformes embarquées, 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'écosystème Arm	Croissante, reconnaissance EU-CC en préparation	Etendue, reconnaissance CCRA pour EAL1 a EAL2 et SOG-IS pour les niveaux supérieurs
Cout typique	Modere a substantiel selon le niveau	Modere a substantiel selon le niveau	Eleve, surtout au-dela d'EAL4+
Reconnaissance réglementaire	Indirecte (cartographies, citations)	Indirecte, croissante	Directe pour certains schèmes nationaux (paiement, identité)

La logique pratique est la suivante: pour un produit IoT de masse sur Arm Cortex-M, PSA Certified L1 puis L2 est généralement le chemin le plus direct, avec une cartographie SESIP3 obtenue de facto. Pour un composant securise haut de gamme avec exigences réglementaires fortes (paiement, identité, eIDAS), Common Criteria reste la voie historique, éventuellement combinée a PSA Certified L3 ou SESIP4/5. Pour un produit multi-architecture (incluant RISC-V ou Arm), SESIP offre une portabilité légèrement superieure.

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

PSA Certified L1 reprend très directement les exigences de gouvernance d'ETSI EN 303 645 et de NIST 8259A. Un fabricant ayant produit un dossier d'auto-évaluation 303 645 dispose déjà de la majorité des réponses au questionnaire L1.

Cote régulation européenne, la directive RED 3.3 entrée en application le 1er août 2025 impose la conformité a trois exigences essentielles (3.3(d) protection des réseaux, 3.3(e) protection des données personnelles, 3.3(f) protection contre la fraude) pour tout équipement radio connecte a internet. La voie formelle de présomption de conformité passe par la serie de normes harmonisées EN 18031, et non par PSA Certified. Un certificat PSA L1 ou L2 peut néanmoins être cite dans le dossier technique au titre de l'article 3.3, en complément, ou comme élément de démonstration de l'état de l'art. Il n'ouvre pas a lui seul la présomption de conformité.

Cote Etats-Unis, NISTIR 8425 (Recommended Cybersecurity Requirements for Consumer-Grade Routers, 2022) et le US Cyber Trust Mark adoptent une logique de capacités de sécurité 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 décembre 2027, étendra l'obligation de cybersécurité a tous les produits avec éléments numériques mis sur le marche européen, qu'ils soient radio ou non. Les normes harmonisées du CRA sont en cours d'élaboration via le mandat de standardisation de la Commission européenne aux organismes européens de normalisation.

Plusieurs catégories de produits seront classées importantes (Class I) ou critiques (Class II) avec des régimes d'évaluation tierce-partie obligatoires. Pour ces catégories, PSA Certified L2 ou L3, ou un certificat SESIP équivalent, est susceptible d'être reconnu comme moyen de preuve de conformité, sous reserve de la publication des normes harmonisées et des actes delegues correspondants. La cartographie precise reste a etablir.

A court terme, la position raisonnable est de ne pas considérer PSA Certified comme une voie alternative au CRA, mais comme un investissement durable dont une fraction substantielle pourra être re-valorisee lorsque les normes CRA seront publiées.

Pieges fréquents au cadrage

Confondre framework PSA et PSA Certified

Le piege le plus répandu cote ingénierie consiste a affirmer que le produit "implemente PSA" sans avoir engage de certification. C'est correct techniquement (le framework est librement implémentable), mais incorrect commercialement: aucun logo PSA Certified ne peut être 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 bibliothèque cryptographique communique parfois sur sa Functional API Certification (Mbed TLS, par exemple) en laissant entendre que les produits qui l'intègrent sont securises au sens PSA. Ce n'est pas le cas: la Functional API Certification valide une interface logicielle, pas une architecture de sécurité. Un produit intégrant une bibliothèque Functional API certifiée peut être complètement insécure 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, intégrateurs smart home) ont commence a exiger PSA Certified L2 dans leurs cahiers des charges, en particulier pour les composants exposes (passerelles, hubs, cameras). Présenter 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 évaluation L2. Une configuration SAU mal posée sur Cortex-M, un périphérique partage sans médiation, une variable globale traversant la frontière: chacun de ces défauts est detecte en laboratoire et invalide l'évaluation. L'audit interne de l'isolation, avec un outillage adapte (Trusted Firmware-M de reference), doit être realise avant l'entrée en laboratoire.

Sous-estimer les itérations laboratoire

Une évaluation L2 sans rapport interne préalable produit souvent plusieurs cycles d'analyse, avec corrections firmware ou matérielles entre chaque iteration. Le calendrier doit prévoir ces itérations: viser L2 en six semaines calendaires sans pre-évaluation interne est généralement irréaliste.

Croire que L2 dispense d'une revue cryptographique

Level 2 valide l'implémentation correcte des services cryptographiques au sens du Protection Profile, mais il ne couvre pas exhaustivement la qualité des protocoles applicatifs construits par-dessus. Une revue cryptographique du protocole métier (typiquement TLS, MQTT-S, LwM2M-DTLS, protocoles propriétaires) reste nécessaire en complément.

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 présenter comme un L1 affaibli expose a une perte de crédibilité vis-a-vis d'un acheteur informe.

Pour un fabricant: cadrer la demarche

Voir aussi

• SESIP: méthodologie d'évaluation cybersécurité IoT
• TPM 2.0 et sécurité matérielle TCG
• Common Criteria (ISO/IEC 15408) : sécurité IT
• ETSI EN 303 645 : cybersécurité IoT consommateur
• CRA : Cyber Resilience Act, exigences UE numérique
• IEC 62443 (ISA-99), cybersécurité des systèmes industriels

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

Trois étapes structurent un cadrage sérieux:

1. Determiner le niveau cible. Modele de menace, marche vise, exigences contractuelles des donneurs d'ordre, anticipation réglementaire (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 réalistes sur une puce dont le silicium est lui-même 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. Démarrer L2 sur une plateforme sans support du PSA-RoT est généralement contre-productif.
3. Pre-évaluation interne avant entrée en laboratoire. Tests d'isolation, revue de l'analyse de menaces TMSA, verification de la conformité aux API. Cette phase réduit substantiellement la durée de l'évaluation laboratoire et le nombre d'itérations.

Pour la dimension réglementaire européenne (RED 3.3, CRA, EN 18031), voir le pillier RED qui detaille les voies de présomption de conformité et leur articulation avec les schèmes 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: cybersécurité IoT consommateur, base de PSA Certified L1
• Cyber Resilience Act: régulation européenne applicable a partir de décembre 2027
• Pillier RED: cadre général radio européen et article 3.3
• Glossaire: définitions 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, méthodologie d'évaluation 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, Profile of the IoT Core Baseline for Consumer IoT Products , 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/