IEC 62541-2:2026

IEC 62541-2 ®
Edition 1.0 2026-02
NORME
INTERNATIONALE
Architecture unifiée OPC -
Partie 2: Modèle de sécurité
ICS 25.040  ISBN 978-2-8327-1035-7

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC -  IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org
Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
Published détaille les nouvelles publications parues. dans 25 langues additionnelles. Egalement appelé
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.

Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
SOMMAIRE
AVANT-PROPOS . 4
1 Domaine d'application . 6
2 Références normatives . 6
3 Termes, définitions, abréviations et conventions . 6
3.1 Termes et définitions. 6
3.2 Abréviations . 12
3.3 Conventions pour les figures du modèle de sécurité . 12
4 Architecture de sécurité OPC UA . 13
4.1 Environnement de sécurité OPC UA . 13
4.2 Objectifs de sécurité . 14
4.2.1 Vue d'ensemble . 14
4.2.2 Authentification . 15
4.2.3 Autorisation . 15
4.2.4 Confidentialité . 15
4.2.5 Intégrité . 15
4.2.6 Non-répudiation . 15
4.2.7 Vérifiabilité . 15
4.2.8 Disponibilité . 15
4.3 Menaces pour la sécurité des systèmes OPC UA . 16
4.3.1 Vue d'ensemble . 16
4.3.2 Déni de service . 16
4.3.3 Écoute illicite . 17
4.3.4 Usurpation de messages . 17
4.3.5 Altération de messages . 18
4.3.6 Rediffusion de messages . 18
4.3.7 Messages mal formés . 18
4.3.8 Profilage du Serveur . 18
4.3.9 Détournement de session . 19
4.3.10 Serveur malveillant . 19
4.3.11 Éditeur malveillant . 19
4.3.12 Compromission des authentifiants d'utilisateur . 19
4.3.13 Répudiation . 20
4.4 Relation entre l'OPC UA et la sécurité du site . 20
4.5 Architecture de sécurité OPC UA . 21
4.5.1 Vue d'ensemble . 21
4.5.2 Client/Serveur . 22
4.5.3 Publication/Abonnement . 23
4.6 SecurityPolicies . 24
4.7 Profils de sécurité . 25
4.8 Paramètres du mode de sécurité . 25
4.9 Authentification de l'utilisateur . 25
4.10 Authentification de l'application . 26
4.11 Autorisation de l'utilisateur . 26
4.12 Rôles . 26
4.13 Services relatifs à la sécurité OPC UA . 27
4.14 Audit . 28
4.14.1 Généralités . 28
4.14.2 Client et Serveur uniques . 29
4.14.3 Serveur de regroupement . 30
4.14.4 Regroupement par l'intermédiaire d'un Serveur sans fonction d'audit . 31
4.14.5 Serveur de regroupement avec distribution de service . 32
5 Rapprochement relatif à la sécurité . 32
5.1 Rapprochement des menaces avec les mécanismes de sécurité OPC UA . 32
5.1.1 Vue d'ensemble . 32
5.1.2 Déni de service . 33
5.1.3 Écoute illicite . 35
5.1.4 Usurpation de messages . 35
5.1.5 Altération de messages . 35
5.1.6 Rediffusion de messages . 35
5.1.7 Messages mal formés . 36
5.1.8 Profilage du Serveur . 36
5.1.9 Détournement de session . 36
5.1.10 Serveur ou Éditeur malveillant . 36
5.1.11 Compromission des authentifiants d'utilisateur . 36
5.1.12 Répudiation . 37
5.2 Rapprochement des objectifs avec les mécanismes de sécurité OPC UA . 37
5.2.1 Vue d'ensemble . 37
5.2.2 Authentification de l'application . 37
5.2.3 Authentification de l'utilisateur . 37
5.2.4 Autorisation . 38
5.2.5 Confidentialité . 38
5.2.6 Intégrité . 38
5.2.7 Vérifiabilité . 38
5.2.8 Disponibilité . 39
6 Considérations relatives à la mise en œuvre et au déploiement . 39
6.1 Vue d'ensemble . 39
6.2 Délais d'attente appropriés . 39
6.3 Traitement strict des messages . 39
6.4 Génération de nombres aléatoires . 40
6.5 Paquets spéciaux et réservés . 40
6.6 Limitation de débit et commande de flux . 41
6.7 Accès administratif . 41
6.8 Clés cryptographiques . 41
6.9 Recommandations relatives aux alarmes. 41
6.10 Accès au programme . 42
6.11 Gestion des Événements d'Audit . 42
6.12 Rôles OAuth2, JWT et User . 42
6.13 HTTPS, TLS et Websockets . 43
6.14 Connexion inversée . 43
6.15 Mots de passe . 43
6.16 Autres considérations relatives à la sécurité . 43
7 Services non sécurisés . 43
7.1 Vue d'ensemble . 43
7.2 Découverte multidiffusion . 44
7.3 Sécurité du Serveur de Découverte global . 44
7.3.1 Vue d'ensemble . 44
7.3.2 GDS malveillant . 45
7.3.3 Menaces contre un GDS . 45
7.3.4 Menaces pour la gestion des certificats . 45
8 Gestion des certificats . 46
8.1 Vue d'ensemble . 46
8.2 Gestion des certificats autosignés . 46
8.3 Gestion des certificats signés par une CA . 47
8.4 Gestion des certificats GDS . 48
8.4.1 Vue d'ensemble . 48
8.4.2 Gestion des certificats de développeurs . 49
Annexe A (informative) Mapping avec l'IEC 62443-4-2 . 52
Bibliographie . 66

Figure 1 – Exemple de réseau OPC UA . 14
Figure 2 – Architecture de sécurité OPC UA – Client/Serveur. 21
Figure 3 – Architecture de sécurité OPC UA – Éditeur/Abonné . 21
Figure 4 – Vue d'ensemble des Rôles . 27
Figure 5 – Serveurs simples . 29
Figure 6 – Serveurs de regroupement . 30
Figure 7 – Regroupement par l'intermédiaire d'un Serveur sans fonction d'audit . 31
Figure 8 – Serveur de regroupement avec distribution de service . 32
Figure 9 – Traitement manuel des certificats . 47
Figure 10 – Traitement des certificats de CA . 48
Figure 11 – Traitement des certificats . 50

Tableau 1 – Récapitulatif du rapprochement des menaces avec les mécanismes de
sécurité . 33
Tableau A.1 – Mapping de l'IEC 62443 – FR 1: Contrôle d'identification et
d'authentification . 53
Tableau A.2 – Mapping de l'IEC 62443 – FR 2: Contrôle d'utilisation . 56
Tableau A.3 – Mapping de l'IEC 62443 – FR 3: Intégrité du système. 58
Tableau A.4 – Mapping de l'IEC 62443 – FR 4: Confidentialité des données . 62
Tableau A.5 – Mapping de l'IEC 62443 – FR 5: Transfert de données limité . 63
Tableau A.6 – Mapping de l'IEC 62443 – FR 6: Réponse appropriée aux événements . 63
Tableau A.7 – Mapping de l'IEC 62443 – FR 7: Disponibilité des ressources . 64

COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE
____________
Architecture unifiée OPC -
Partie 2: Modèle de sécurité
AVANT-PROPOS
1) La Commission Électrotechnique Internationale (IEC) est une organisation mondiale de normalisation composée
de l'ensemble des comités électrotechniques nationaux (Comités nationaux de l'IEC). L'IEC a pour objet
de favoriser la coopération internationale pour toutes les questions de normalisation dans les domaines
de l'électricité et de l'électronique. À cet effet, l'IEC – entre autres activités – publie des Normes internationales,
des Spécifications techniques, des Rapports techniques, des Spécifications accessibles au public (PAS) et
des Guides (ci-après dénommés "Publication(s) de l'IEC"). Leur élaboration est confiée à des comités d'études,
aux travaux desquels tout Comité national intéressé par le sujet traité peut participer. Les organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'IEC, participent également
aux travaux. L'IEC collabore étroitement avec l'Organisation Internationale de Normalisation (ISO), selon
des conditions fixées par accord entre les deux organisations.
2) Les décisions ou accords officiels de l'IEC concernant les questions techniques représentent, dans la mesure
du possible, un accord international sur les sujets étudiés, étant donné que les Comités nationaux de l'IEC
intéressés sont représentés dans chaque comité d'études.
3) Les Publications de l'IEC se présentent sous la forme de recommandations internationales et sont agréées
comme telles par les Comités nationaux de l'IEC. Tous les efforts raisonnables sont entrepris afin que l'IEC
s'assure de l'exactitude du contenu technique de ses publications; l'IEC ne peut pas être tenue responsable
de l'éventuelle mauvaise utilisation ou interprétation qui en est faite par un quelconque utilisateur final.
4) Dans le but d'encourager l'uniformité internationale, les Comités nationaux de l'IEC s'engagent, dans toute
la mesure possible, à appliquer de façon transparente les Publications de l'IEC dans leurs publications nationales
et régionales. Toutes divergences entre toutes Publications de l'IEC et toutes publications nationales ou
régionales correspondantes doivent être indiquées en termes clairs dans ces dernières.
5) L'IEC elle-même ne fournit aucune attestation de conformité. Des organismes de certification indépendants
fournissent des services d'évaluation de conformité et, dans certains secteurs, accèdent aux marques
de conformité de l'IEC. L'IEC n'est responsable d'aucun des services effectués par les organismes de certification
indépendants.
6) Tous les utilisateurs doivent s'assurer qu'ils sont en possession de la dernière édition de cette publication.
7) Aucune responsabilité ne doit être imputée à l'IEC, à ses administrateurs, employés, auxiliaires ou mandataires,
y compris ses experts particuliers et les membres de ses comités d'études et des Comités nationaux de l'IEC,
pour tout préjudice causé en cas de dommages corporels et matériels, ou de tout autre dommage de quelque
nature que ce soit, directe ou indirecte, ou pour supporter les coûts (y compris les frais de justice) et les dépenses
découlant de la publication ou de l'utilisation de cette Publication de l'IEC ou de toute autre Publication de l'IEC,
ou au crédit qui lui est accordé.
8) L'attention est attirée sur les références normatives citées dans cette publication. L'utilisation de publications
référencées est obligatoire pour une application correcte de la présente publication.
9) L'IEC attire l'attention sur le fait que la mise en application du présent document peut entraîner l'utilisation d'un ou
de plusieurs brevets. L'IEC ne prend pas position quant à la preuve, à la validité et à l'applicabilité de tout droit
de brevet revendiqué à cet égard. À la date de publication du présent document, l'IEC n'avait pas reçu notification
qu'un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois, il y a lieu d'avertir
les responsables de la mise en application du présent document que des informations plus récentes
sont susceptibles de figurer dans la base de données de brevets, disponible à l'adresse https://patents.iec.ch.
L'IEC ne saurait être tenue pour responsable de ne pas avoir identifié tout ou partie de tels droits de brevet.
L'IEC 62541-2 a été établie par le sous-comité 65E: Les dispositifs et leur intégration
dans les systèmes de l'entreprise, du comité d'études 65 de l'IEC: Mesure, commande et
automation dans les processus industriels. Il s'agit d'une Norme internationale.
Cette édition annule et remplace la troisième édition de l’IEC TR 62541-2 parue en 2020. Cette
édition constitue une révision technique.
Le texte de cette Norme internationale est issu des documents suivants:
Projet Rapport de vote
65E/1201/FDIS 65E/1206/RVD
Le rapport de vote indiqué dans le tableau ci-dessus donne toute information sur le vote ayant
abouti à son approbation.
La langue employée pour l'élaboration de cette Norme internationale est l'anglais.
Ce document a été rédigé selon les Directives ISO/IEC, Partie 2, il a été développé
selon les Directives ISO/IEC, Partie 1 et les Directives ISO/IEC, Supplément IEC, disponibles
sous www.iec.ch/members_experts/refdocs. Les principaux types de documents développés
par l'IEC sont décrits plus en détail sous www.iec.ch/publications.
Dans l'ensemble du présent document et dans les autres parties de la série, certaines
conventions de document sont utilisées:
Le format italique est utilisé pour mettre en évidence un terme défini ou une définition
qui apparaît à l'article "Termes et définitions" dans l'une des parties de la série.
Le format italique est également utilisé pour mettre en évidence le nom d'un paramètre d'entrée
ou de sortie de service, ou le nom d'une structure ou d'un élément de structure habituellement
défini dans les tableaux.
Par ailleurs, les termes et les noms en italique sont souvent écrits en camel-case
(pratique qui consiste à joindre, sans espace, les éléments des mots ou expressions composés,
la première lettre de chaque élément étant en majuscule). Par exemple, le terme défini est
AddressSpace et non Espace d'Adressage. Cela permet de mieux comprendre qu'il existe
une définition unique pour AddressSpace, et non deux définitions distinctes pour Espace et
pour Adressage.
Une liste de toutes les parties de la série IEC 62541, publiées sous le titre général Architecture
unifiée OPC, se trouve sur le site web de l'IEC.
Le comité a décidé que le contenu de ce document ne sera pas modifié avant la date de stabilité
indiquée sur le site web de l'IEC sous webstore.iec.ch dans les données relatives au document
recherché. À cette date, le document sera
– reconduit,
– supprimé, ou
– révisé.
1 Domaine d'application
La présente partie de l'IEC 62541 décrit le modèle de sécurité de l'Architecture unifiée OPC
(OPC UA). Elle décrit les menaces pour la sécurité des environnements physiques, matériels
et logiciels dans lesquels l'OPC UA est destinée à fonctionner. Elle décrit de quelle manière
l'OPC UA s'appuie sur d'autres normes de sécurité. Elle fournit une définition des termes
de sécurité communs utilisés dans la présente partie et dans les autres parties de la série
IEC 62541. Elle donne une vue d'ensemble des fonctions de sécurité spécifiées dans d'autres
parties de la série et en décrit le concept. Elle fait référence aux services, mappings et Profils
spécifiés de manière normative dans d'autres parties de la série IEC 62541. Elle fournit
des suggestions ou des lignes directrices sur les meilleures pratiques relatives à la mise
en œuvre de la sécurité. Aucune ambiguïté apparente entre le présent document et
l'une des autres parties normatives ne supprime ni ne réduit l'exigence spécifiée dans l'autre
partie normative.
Il existe de nombreux aspects différents de la sécurité qui sont traités lors du développement
d'applications. Cependant, étant donné que l'OPC UA spécifie un protocole de communication,
l'attention est portée sur la sécurisation des données échangées entre les applications.
Cela ne signifie pas qu'un développeur d'applications peut ignorer les autres aspects
de la sécurité, comme la protection des données persistantes contre toute falsification.
Il est important que les développeurs examinent tous les aspects de la sécurité et décident
de la manière dont ces aspects peuvent être traités dans l'application. Les fonctions de sécurité
communes pour les commandes industrielles sont définies dans l'IEC 62443-4-2;
elles sont mises en corrélation avec l'OPC UA à l'Annexe A.
Le présent document s'adresse aux lecteurs qui développeront des applications OPC UA. Il
s'applique également aux utilisateurs finaux qui souhaitent comprendre les différentes fonctions
de sécurité fournies par l'OPC UA. Il fournit, par ailleurs, certaines recommandations
qui peuvent être appliquées lors du déploiement de systèmes. Ces recommandations
sont génériques par nature, car les détails dépendent de la mise en œuvre réelle
des applications OPC UA et des choix effectués pour la sécurité du site.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu'ils constituent, pour tout ou partie
de leur contenu, des exigences du présent document. Pour les références datées, seule
l'édition citée s'applique. Pour les références non datées, la dernière édition du document
de référence s'applique (y compris les éventuels amendements).
IEC 62541-1, Architecture unifiée OPC - Partie 1: Vue d'ensemble et concepts
3 Termes, définitions, abréviations et conventions
3.1 Termes et définitions
Pour les besoins du présent document, les termes et définitions de l'IEC 62541-1
ainsi que les suivants s'appliquent.
L'ISO et l'IEC tiennent à jour des bases de données terminologiques destinées à être utilisées
en normalisation, consultables aux adresses suivantes:
– IEC Electropedia: disponible à l'adresse https://www.electropedia.org/
– ISO Online browsing platform: disponible à l'adresse https://www.iso.org/obp
3.1.1
AccessRestriction
limite sur les circonstances dans lesquelles une opération, telle qu'une lecture, une écriture ou
un appel, peut être exécutée sur un Nœud
Note 1 à l'article: Des opérations ne peuvent être réalisées sur un Nœud que si le Client possède les Permissions
nécessaires et satisfait à toutes les AccessRestrictions.
3.1.2
AccessToken
document signé numériquement qui certifie que le sujet a le droit d'accéder à une Ressource
Note 1 à l'article: Le document inclut le nom du sujet et de la Ressource à laquelle il accède.
3.1.3
ApplicationInstance
installation individuelle d'un programme exécuté sur un ordinateur donné
Note 1 à l'article: Il peut y avoir plusieurs ApplicationInstances de la même application qui s'exécute simultanément
sur plusieurs ordinateurs ou, éventuellement, sur le même ordinateur.
3.1.4
ApplicationInstanceCertificate
Certificat d'une ApplicationInstance donnée qui a été installée sur un hôte donné
Note 1 à l'article: Des installations différentes du même produit logiciel ont des ApplicationInstanceCertificates
différents. L'emploi d'un ApplicationInstanceCertificate pour des utilisations autres que celles décrites
dans la présente spécification peut sensiblement réduire la sécurité fournie par l'ApplicationInstanceCertificate et
il convient donc de l'éviter.
Note 2 à l'article: Également écrit sous la forme Certificat ApplicationInstance.
3.1.5
Cryptographie asymétrique
méthode de Cryptographie qui utilise une paire de clés, dont l'une est désignée Clé privée et
gardée secrète, et l'autre, appelée Clé publique, est disponible au public
Note 1 à l'article: La Cryptographie asymétrique est également appelée "cryptographie à clé publique".
Dans un algorithme de Chiffrement asymétrique, lorsqu'une entité "A" exige une Confidentialité des données
envoyées à l'entité "B", l'entité "A" chiffre alors les données à l'aide d'une Clé publique fournie par l'entité "B".
Seule l'entité "B" possède la Clé privée correspondante nécessaire pour déchiffrer les données. Dans un algorithme
de Signature numérique asymétrique, lorsqu'une entité "A" exige l'Intégrité du message ou exige de fournir
une Authentification pour les données envoyées à l'entité "B", l'entité A utilise sa Clé privée pour signer les données.
Pour vérifier la signature, l'entité B utilise la Clé publique correspondante fournie par l'entité A. Dans un algorithme
d'accord de clé asymétrique, l'entité A et l'entité B envoient chacune leur propre Clé publique à l'autre entité. Chacune
utilise alors sa propre Clé privée et la Clé publique de l'autre entité pour calculer la nouvelle valeur de clé,
conformément à l'IS Glossary.
3.1.6
Chiffrement asymétrique
mécanisme utilisé par la Cryptographie asymétrique pour chiffrer des données avec la Clé
publique d'une entité et pour déchiffrer des données avec la Clé privée associée
3.1.7
Signature asymétrique
mécanisme utilisé par la Cryptographie asymétrique pour signer des données avec la Clé privée
d'une entité et pour vérifier la signature des données à l'aide de la Clé publique associée
3.1.8
Vérifiabilité
objectif de sécurité qui assure que toute action ou toute activité d'un système peut être
enregistrée
3.1.9
Audit
suivi des actions et des activités dans le système, y compris les activités relatives à la sécurité,
où des enregistrements d'Audit peuvent être utilisés pour examiner et vérifier les opérations
du système
3.1.10
Authentification
processus qui assure que l'identité d'une entité telle qu'un Client, un Serveur, un Éditeur ou
un utilisateur peut être vérifiée
3.1.11
Autorisation
capacité à accorder l'accès à une ressource système
Note 1 à l'article: Il convient que l'Autorisation d'accès aux ressources soit fondée sur le principe
du "besoin d'en connaître". Il est important que l'accès soit limité dans un système.
3.1.12
AuthorizationService
Serveur qui valide une demande d'accès à une Ressource et retourne un AccessToken
qui donne accès à la Ressource
Note 1 à l'article: L'AuthorizationService est également appelé STS (Security Token Service, service de jeton
de sécurité) dans d'autres normes.
3.1.13
Disponibilité
objectif de sécurité qui assure que le système fonctionne normalement. Autrement dit, aucun
service n'a été compromis au point de devenir indisponible ou gravement dégradé
3.1.14
Autorité de certification
entité qui peut émettre des Certificats, également connue sous le nom de CA
Note 1 à l'article: Le Certificat certifie la propriété d'une Clé publique par le sujet nommé du Certificat. Cela permet
à des tiers (des parties dépendantes) de s'appuyer sur des signatures ou des assertions faites par la Clé privée
qui correspond à la Clé publique certifiée. Dans ce modèle de relation de confiance, une CA est un tiers de confiance
qui est à la fois le sujet (propriétaire) du Certificat et la partie qui dépend du Certificat. Les CA sont caractéristiques
de nombreux schémas d'Infrastructure à clés publiques (PKI, Public Key Infrastructure).
Note 2 à l'article: Un système de CA privée (ou une sous-CA privée) peut être utilisé, sous réserve que toutes
les parties lui fassent confiance.
3.1.15
CertificateStore
lieu persistant où sont stockées les Certificats et les listes de révocation de Certificats (CRL)
Note 1 à l'article: Il peut s'agir d'une structure de fichier résidant sur un disque ou, dans le cas de plateformes
Windows, d'un emplacement du Registre Windows.
3.1.16
Revendication
déclaration dans un AccessToken qui atteste d'informations concernant le sujet dont le Service
d'autorisation sait qu'elles sont vraies
Note 1 à l'article: Les Revendications peuvent inclure le nom d'utilisateur, l'adresse e-mail et les Rôles attribués
au sujet.
3.1.17
Confidentialité
objectif de sécurité qui assure la protection des données contre la lecture par des parties
auxquelles elles ne sont pas destinées
3.1.18
Cryptographie
algorithme qui transforme une information claire et significative en une forme chiffrée et
inintelligible à l'aide d'un algorithme et d'une clé
3.1.19
Système de gestion de la cybersécurité
programme conçu par une organisation dans le but de maintenir la sécurité des actifs
de l'ensemble de l'organisation à un niveau établi de Confidentialité, d'Intégrité et
de Disponibilité, qu'ils concernent la partie commerciale ou la partie systèmes d'automatisation
industrielle et de commande de l'organisation
3.1.20
Signature numérique
valeur calculée à l'aide d'un algorithme cryptographique et ajoutée aux données de sorte
que tout destinataire des données puisse utiliser la signature pour vérifier l'origine et l'Intégrité
des données
3.1.21
Intégrité
objectif de sécurité qui assure que les informations n'ont pas été modifiées ou détruites
de manière non autorisée
Note 1 à l'article: Plus d'informations peuvent être obtenues en consultant l'IS Glossary.
3.1.22
Fournisseur d'identité
Serveur qui vérifie les authentifiants fournis par un Principal de sécurité et qui retourne un jeton
pouvant être transmis à un Service d'autorisation associé
3.1.23
Algorithme d'échange de clés
protocole utilisé pour établir un chemin de communication sécurisé entre deux entités
dans un environnement non sécurisé, par lequel les deux entités appliquent un algorithme
spécifique pour échanger en toute sécurité des clés secrètes utilisées pour sécuriser
la communication entre elles
Note 1 à l'article: Le protocole Handshake spécifié dans TLS est un exemple type d'Algorithme d'échange de clés.
3.1.24
Signature de message
Signature numérique utilisée pour assurer l'Intégrité des Messages qui sont envoyés entre
deux entités
Note 1 à l'article: Il existe plusieurs manières de générer et de vérifier les Signatures de message,
mais elles peuvent être classées en deux catégories: les approches symétriques (voir 3.1.35) et les approches
asymétriques (voir 3.1.5).
3.1.25
Non-répudiation
aptitude à démontrer l'occurrence d'un événement ou d'une action revendiqué(e) et ses entités
d'origine
Note 1 à l'article: La non-répudiation a pour objet de résoudre les litiges quant à la survenue ou pas de l'événement
ou de l'action et à l'implication des entités dans l'événement.
Note 2 à l'article: Cette définition est issue de l'IEC 62443-4-2 et peut être différente de la définition utilisée
dans d'autres secteurs.
3.1.26
Nonce
nombre aléatoire qui est utilisé une fois, généralement par des algorithmes qui génèrent
des clés de sécurité
3.1.27
Permission
droit d'exécuter une opération, par exemple une lecture, une écriture ou un appel, sur un Nœud
3.1.28
Clé privée
composante secrète d'une paire de clés cryptographiques utilisée pour la Cryptographie
asymétrique
Note 1 à l'article: La Clé publique et la Clé privée sont toujours générées sous la forme d'une paire.
Si l'une d'elles est mise à jour, l'autre l'est également.
3.1.29
Clé publique
composante divulguée publiquement d'une paire de clés cryptographiques utilisée
pour la Cryptographie asymétrique
Note 1 à l'article: Voir l'IS Glossary.
Note 2 à l'article: La Clé publique et la Clé privée sont toujours générées sous la forme d'une paire.
Si l'une d'elles est mise à jour, l'autre doit également l'être.
3.1.30
Infrastructure à clés publiques
ensemble de matériels, logiciels, personnes, politiques et procédures nécessaires pour créer,
gérer, stocker, distribuer et révoquer des Certificats fondés sur une Cryptographie asymétrique
Note 1 à l'article: Les principales fonctions d'ICP consistent à enregistrer les utilisateurs et à délivrer
leurs Certificats à clé publique, à révoquer les Certificats si nécessaire et à archiver les données nécessaires
pour valider les Certificats. Les paires de clés pour la Confidentialité des données peuvent être générées
par une Autorité de certification (CA), mais il est préférable que le propriétaire de la Clé privée génère la paire
de clés en local, sous réserve qu'il possède une fonctionnalité de génération de clés de confiance, car cela améliore
la sécurité du fait que la Clé privée n'est jamais transmise à la CA. Voir ICP et X.509v3 pour plus d'informations
sur les Infrastructures à clés publiques.
3.1.31
Ressource
entité sécurisée à laquelle une application accède
Note 1 à l'article: Une Ressource est généralement un Serveur.
3.1.32
Rôle
fonction assumée par un Client lorsqu'il accède à un Serveur
Note 1 à l'article: Un Rôle peut faire référence à une fonction professionnelle spécifique, telle qu'un opérateur ou
un ingénieur.
3.1.33
SecurityKeyService
Serveur qui accepte des AccessTokens émis par le Service d'autorisation et qui retourne
des clés de sécurité pouvant être utilisées pour accéder à la Ressource spécifiée.
Note 1 à l'article: Les clés sont généralement utilisées pour les opérations de cryptographie telles que le chiffrement
ou le déchiffrement de messages envoyés sur un flux PubSub.
3.1.34
Canal sécurisé
dans l'OPC UA, chemin de communication établi entre un Client et un Serveur OPC UA
qui se sont authentifiés en utilisant certains services OPC UA et pour lesquels des paramètres
de sécurité ont été négociés et appliqués
3.1.35
Cryptographie symétrique
branche de cryptographie impliquant des algorithmes qui utilisent la même clé pour deux étapes
différentes de l'algorithme (comme le chiffrement et le déchiffrement, ou la création de signature
et la vérification de signature)
Note 1 à l'article: Voir l'IS Glossary.
3.1.36
Chiffrement symétrique
mécanisme utilisé par la Cryptographie symétrique pour le chiffrement et le déchiffrement
de données avec une clé cryptographique partagée par deux entités
3.1.37
SecurityGroup
Éditeur(s) et Abonné(s) qui utilisent un contexte de sécurité partagé
Note 1 à l'article: Ce contexte peut inclure des clés de partage.
3.1.38
Signature symétrique
mécanisme utilisé par la Cryptographie symétrique pour la signature de données avec une clé
cryptographique partagée par deux entités
Note 1 à l'article: La signature est ensuite validée en générant à nouveau la signature des données et en comparant
ces deux signatures. Si elles sont identiques, la signature est alors valide; sinon, la clé ou les données
sont différentes des deux entités.
3.1.39
TrustList
liste des Certificats auxquels une Application OPC UA, par sa configuration, fait confiance
3.1.40
Transport Layer Security
protocole normalisé pour la création de Canaux sécurisés sur des réseaux IP
3.1.41
Certificat X.509
Certificat dans l'un des formats définis par X.509 version 1, 2 ou 3
Note 1 à l'article: Un Certificat X.509 contient une séquence d'éléments de données et comporte une Signature
numérique calculée sur cette séquence. L'OPC UA utilise uniquement la V3.
3.2 Abréviations
AES (Advanced Encryption Standard) Protocole AES
CA (Certificate Authority) Autorité de certification
CRL (Certificate Revocation List) Liste de révocation de certificat
CSMS (Cyber Security Management System) Système de gestion de la cybersécurité
DNS (Domain Name System) Système de noms de domaine
DSA (Digital Signature Algorithm) Algorithme de signature numérique
ECDH (Elliptic Curve Diffie-Hellman) Algorithme Diffie-Hellman fondé sur
les courbes elliptiques
ECDSA (Elliptic Curve Digital Signature Algorithme de signature numérique fondé
Algorithm) sur les courbes elliptiques
GDS (Global Discovery Server) Serveur de découverte global
HMAC (Hash-based Message Authentication Code d'authentification de message fondé
Code) sur un hachage
JSON (JavaScript Object Notation) Notation objet issue de JavaScript
JWT (JSON Web Token) Jeton Web JSON
NIST (National Institute of Standard and Institut national des normes et
Technology) de la technologie
PKI (Public Key Infrastructure) Infrastructure à clés publiques
RSA (Rivest-Shamir-Adleman) Algorithme de clé publique pour la signature
ou le chiffrement
SHA (Secure Hash Algorithm) Algorithme de hachage sécurisé (il en
existe plusieurs versions, SHA1, SHA256,
etc.)
SKS (Security Key Server) Serveur de clés de sécurité
SSL (Secure Sockets Layer) Protocole SSL
TLS (Transport Layer Security) Protocole TLS
TPM (Trusted Platform Module) Module de plateforme de confiance
UA (Unified Architecture) Architecture unifiée
UACP (Unified Architecture Connection Protocole de connexion de l'Architecture
Protocol) unifiée
UADP (Unified Architecture Datagram Protocole datagramme de l'Architecture
Protocol) unifiée
URI (Uniform Resource Identifier) Identificateur uniforme de ressources
XML (Extensible Mark-up Language) Langage de balisage étendu

3.3 Conventions pour les figures du modèle de sécurité
Les figures du présent document n'utilisent aucune convention particulière.
Toutes les conventions utilisées dans une figure particulière sont expliquées pour la figure
en question.
4 Architecture de sécurité OPC UA
4.1 Environnement de sécurité OPC UA
L'OPC UA est un protocole utilisé entre les composants impliqués dans l'exploitation
d'une installation industrielle à plusieurs niveaux: de la gestion d'entreprise de haut niveau
à la commande directe de processus de bas niveau d'un appareil. L'utilisation de l'OPC UA
pour la gestion d'entreprise implique des relations avec les clients et les fournisseurs.
Elle peut constituer une cible attractive pour l'espionnage ou le sabotage industriel, et
peut également être exposée à des menaces par l'intermédiaire de logiciels malveillants
non ciblés tels que des vers circulant sur des réseaux publics. Une interruption
des communications au niveau de la commande de processus peut engendrer des pertes
financières, compromettre la sécurité des employés et la sécurité publique, voire occasionner
des dégâts environnementaux.
L'OPC UA est destinée à être déployée dans différents environnements d'exploitation,
caractérisés par différentes hypothèses en ce qui concerne les menaces et l'accessibilité,
ainsi que par une diversité de politiques de sécurité et de régimes d'application de la loi.
L'OPC UA fournit donc un ensemble souple de mécanismes de sécurité. La Figure 1 représente
une combinaison de ces environnements. Certaines Applications OPC UA se trouvent
sur le même hôte et peuvent facilement être protégées des att
...

IEC 62541-2 ®
Edition 1.0 2026-02
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
OPC unified architecture –
Part 2: Security Model
Architecture unifiée OPC -
Partie 2: Modèle de sécurité
ICS 25.040  ISBN 978-2-8327-1035-7

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or
by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either
IEC or IEC's member National Committee in the country of the requester. If you have any questions about IEC copyright
or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local
IEC member National Committee for further information.

Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni
utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et
les microfilms, sans l'accord écrit de l'IEC ou du Comité national de l'IEC du pays du demandeur. Si vous avez des
questions sur le copyright de l'IEC ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez
les coordonnées ci-après ou contactez le Comité national de l'IEC de votre pays de résidence.

IEC Secretariat Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 www.iec.ch
Switzerland
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigendum or an amendment might have been published.

IEC publications search - IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Discover our powerful search engine and read freely all the
The advanced search enables to find IEC publications by a publications previews, graphical symbols and the glossary.
variety of criteria (reference number, text, technical With a subscription you will always have access to up to date
committee, …). It also gives information on projects, content tailored to your needs.
replaced and withdrawn publications.
Electropedia - www.electropedia.org
IEC Just Published - webstore.iec.ch/justpublished The world's leading online dictionary on electrotechnology,
Stay up to date on all new IEC publications. Just Published containing more than 22 500 terminological entries in English
details all new publications released. Available online and and French, with equivalent terms in 25 additional languages.
once a month by email. Also known as the International Electrotechnical Vocabulary
(IEV) online.
IEC Customer Service Centre - webstore.iec.ch/csc
If you wish to give us your feedback on this publication or
need further assistance, please contact the Customer
Service Centre: sales@iec.ch.
A propos de l'IEC
La Commission Electrotechnique Internationale (IEC) est la première organisation mondiale qui élabore et publie des
Normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.

A propos des publications IEC
Le contenu technique des publications IEC est constamment revu. Veuillez vous assurer que vous possédez l’édition la
plus récente, un corrigendum ou amendement peut avoir été publié.

Recherche de publications IEC -  IEC Products & Services Portal - products.iec.ch
webstore.iec.ch/advsearchform Découvrez notre puissant moteur de recherche et consultez
La recherche avancée permet de trouver des publications gratuitement tous les aperçus des publications, symboles
IEC en utilisant différents critères (numéro de référence, graphiques et le glossaire. Avec un abonnement, vous aurez
texte, comité d’études, …). Elle donne aussi des toujours accès à un contenu à jour adapté à vos besoins.
informations sur les projets et les publications remplacées
ou retirées. Electropedia - www.electropedia.org

Le premier dictionnaire d'électrotechnologie en ligne au
IEC Just Published - webstore.iec.ch/justpublished monde, avec plus de 22 500 articles terminologiques en
Restez informé sur les nouvelles publications IEC. Just anglais et en français, ainsi que les termes équivalents
Published détaille les nouvelles publications parues. dans 25 langues additionnelles. Egalement appelé
Disponible en ligne et une fois par mois par email. Vocabulaire Electrotechnique International (IEV) en ligne.

Service Clients - webstore.iec.ch/csc
Si vous désirez nous donner des commentaires sur cette
publication ou si vous avez des questions contactez-
nous: sales@iec.ch.
CONTENTS
FOREWORD . 4
1 Scope . 6
2 Normative references . 6
3 Terms, definitions, abbreviated terms and conventions . 6
3.1 Terms and definitions . 6
3.2 Abbreviated terms. 11
3.3 Conventions for security model figures. 12
4 OPC UA security architecture . 12
4.1 OPC UA security environment . 12
4.2 Security objectives . 13
4.2.1 Overview . 13
4.2.2 Authentication . 14
4.2.3 Authorization . 14
4.2.4 Confidentiality . 14
4.2.5 Integrity . 14
4.2.6 Non-Repudiation . 14
4.2.7 Auditability . 14
4.2.8 Availability . 14
4.3 Security threats to OPC UA systems . 14
4.3.1 Overview . 14
4.3.2 Denial of Service . 15
4.3.3 Eavesdropping. 16
4.3.4 Message spoofing . 16
4.3.5 Message alteration . 16
4.3.6 Message replay . 17
4.3.7 Malformed Messages . 17
4.3.8 Server profiling . 17
4.3.9 Session hijacking . 17
4.3.10 Rogue Server . 17
4.3.11 Rogue Publisher . 18
4.3.12 Compromising user credentials . 18
4.3.13 Repudiation . 18
4.4 OPC UA relationship to site security . 18
4.5 OPC UA security architecture . 19
4.5.1 Overview . 19
4.5.2 Client / Server . 20
4.5.3 Publish-Subscribe . 21
4.6 SecurityPolicies . 22
4.7 Security Profiles . 23
4.8 Security Mode settings . 23
4.9 User Authentication . 23
4.10 Application Authentication . 24
4.11 User Authorization . 24
4.12 Roles . 24
4.13 OPC UA security related Services . 25
4.14 Auditing . 26
4.14.1 General. 26
4.14.2 Single Client and Server . 26
4.14.3 Aggregating Server . 27
4.14.4 Aggregation through a non-auditing Server . 28
4.14.5 Aggregating Server with service distribution. 28
5 Security reconciliation . 29
5.1 Reconciliation of threats with OPC UA security mechanisms . 29
5.1.1 Overview . 29
5.1.2 Denial of Service . 30
5.1.3 Eavesdropping. 31
5.1.4 Message spoofing . 31
5.1.5 Message alteration . 32
5.1.6 Message replay . 32
5.1.7 Malformed Messages . 32
5.1.8 Server profiling . 32
5.1.9 Session hijacking . 32
5.1.10 Rogue Server or Publisher . 33
5.1.11 Compromising user credentials . 33
5.1.12 Repudiation . 33
5.2 Reconciliation of objectives with OPC UA security mechanisms . 33
5.2.1 Overview . 33
5.2.2 Application Authentication . 33
5.2.3 User Authentication . 34
5.2.4 Authorization . 34
5.2.5 Confidentiality . 34
5.2.6 Integrity . 34
5.2.7 Auditability . 35
5.2.8 Availability . 35
6 Implementation and deployment considerations . 35
6.1 Overview . 35
6.2 Appropriate timeouts . 35
6.3 Strict Message processing . 35
6.4 Random number generation . 36
6.5 Special and reserved packets . 36
6.6 Rate limiting and flow control . 36
6.7 Administrative access . 36
6.8 Cryptographic Keys. 37
6.9 Alarm related guidance . 37
6.10 Program access. 37
6.11 Audit event management . 38
6.12 OAuth2, JWT and User roles. 38
6.13 HTTPS, TLS & Websockets . 38
6.14 Reverse connect. 38
6.15 Passwords . 39
6.16 Additional Security considerations . 39
7 Unsecured Services . 39
7.1 Overview . 39
7.2 Multi Cast Discovery . 39
7.3 Global Discovery Server Security . 39
7.3.1 Overview . 39
7.3.2 Rogue GDS . 40
7.3.3 Threats against a GDS . 40
7.3.4 Certificate management threats . 40
8 Certificate management . 41
8.1 Overview . 41
8.2 Self signed certificate management . 41
8.3 CA Signed Certificate management . 42
8.4 GDS Certificate Management . 43
8.4.1 Overview . 43
8.4.2 Developers Certificate management. 44
Annex A (informative) Mapping to IEC 62443-4-2 . 46
Bibliography . 59

Figure 1 – OPC UA network example . 13
Figure 2 – OPC UA security architecture – Client / Server . 19
Figure 3 – OPC UA security architecture- Publisher - Subscriber . 20
Figure 4 – Role overview . 24
Figure 5 – Simple Servers . 26
Figure 6 – Aggregating Servers. 27
Figure 7 – Aggregation with a non-auditing Server . 28
Figure 8 – Aggregating Server with service distribution . 29
Figure 9 – Manual Certificate handling . 42
Figure 10 – CA Certificate handling . 43
Figure 11 – Certificate handling . 44

Table 1 – Security Reconciliation Threats Summary . 30
Table A.1 – IEC 62443 Mapping FR 1 Identification and authentication control . 47
Table A.2 – IEC 62443 mapping FR 2 Use control . 50
Table A.3 – IEC 62443 Mapping FR 3 System integrity . 52
Table A.4 – IEC 62443 Mapping FR 4 Data confidentiality . 55
Table A.5 – IEC 62443 Mapping FR 5 Restricted data flow . 56
Table A.6 – IEC 62443 Mapping FR 6 Timely response to events . 56
Table A.7 – IEC 62443 Mapping FR 7 Resource availability . 57

INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
OPC unified architecture -
Part 2: Security Model
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international
co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and
in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports,
Publicly Available Specifications (PAS) and Guides (hereafter referred to as "IEC Publication(s)"). Their
preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with
may participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for
Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence between
any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity
assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any
services carried out by independent certification bodies.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) IEC draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). IEC takes no position concerning the evidence, validity or applicability of any claimed patent rights in
respect thereof. As of the date of publication of this document, IEC had not received notice of (a) patent(s), which
may be required to implement this document. However, implementers are cautioned that this may not represent
the latest information, which may be obtained from the patent database available at https://patents.iec.ch. IEC
shall not be held responsible for identifying any or all such patent rights.
IEC 62541-2 has been prepared by subcommittee 65E: Devices and integration in enterprise
systems, of IEC technical committee 65: Industrial-process measurement, control, and
automation. It is an International Standard.
This edition cancels and replaces the third edition of IEC TR 62541-2, published in 2020.This
edition constitutes a technical revision.
The text of this International Standard is based on the following documents:
Draft Report on voting
65E/1201/FDIS 65E/1206/RVD
Full information on the voting for its approval can be found in the report on voting indicated in
the above table.
The language used for the development of this International Standard is English.
This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in
accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available
at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are
described in greater detail at www.iec.ch/publications.
Throughout this document and the other Parts of the series, certain document conventions are
used:
Italics are used to denote a defined term or definition that appears in the "Terms and definitions"
clause in one of the parts of the series.
Italics are also used to denote the name of a service input or output parameter or the name of
a structure or element of a structure that are usually defined in tables.
The italicized terms and names are also often written in camel-case (the practice of writing
compound words or phrases in which the elements are joined without spaces, with each
element's initial letter capitalized within the compound). For example, the defined term is
AddressSpace instead of Address Space. This makes it easier to understand that there is a
single definition for AddressSpace, not separate definitions for Address and Space.
A list of all parts in the IEC 62541 series, published under the general title OPC Unified
Architecture, can be found on the IEC website.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under webstore.iec.ch in the data related to the
specific document. At this date, the document will be
– reconfirmed,
– withdrawn, or
– revised.
1 Scope
This part of IEC 62541 describes the OPC Unified Architecture (OPC UA) security model. It
describes the security threats of the physical, hardware, and software environments in which
OPC UA is expected to run. It describes how OPC UA relies upon other standards for security.
It provides definition of common security terms that are used in this and other parts of the
IEC 62541 series. It gives an overview and concept of the security features that are specified
in other parts of the series. It references services, mappings, and Profiles that are specified
normatively in other parts of the 62541 series. It provides suggestions or best practice
guidelines on implementing security. Any seeming ambiguity between this document and one
of the other normative parts does not remove or reduce the requirement specified in the other
normative part.
There are many different aspects of security that are addressed when developing applications.
However, since OPC UA specifies a communication protocol, the focus is on securing the data
exchanged between applications. This does not mean that an application developer can ignore
the other aspects of security like protecting persistent data against tampering. It is important
that the developers look into all aspects of security and decide how they can be addressed in
the application. Common security features for industrial Controls are defined in IEC 62443-4-2
and OPC UA defined a relationship to them in Annex A.
This document is directed to readers who will develop OPC UA applications. It is also for end
Users that wish to understand the various security features and functionality provided by OPC
UA. It also offers some recommendations that can be applied when deploying systems. These
recommendations are generic in nature since the details would depend on the actual
implementation of the OPC UA applications and the choices made for the site security.
2 Normative references
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.
IEC 62541-1, OPC Unified Architecture - Part 1: Overview and Concepts
3 Terms, definitions, abbreviated terms and conventions
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in IEC 62541-1 and the
following apply.
ISO and IEC maintain terminology databases for use in standardization at the following
addresses:
– IEC Electropedia: available at https://www.electropedia.org/
– ISO Online browsing platform: available at https://www.iso.org/obp
3.1.1
AccessRestriction
limit on the circumstances under which an operation, such as a read, write or a call, can be
performed on a Node
Note 1 to entry: Operations can only be performed on a Node if the Client has the necessary Permissions and has
satisfied all of the AccessRestrictions.
3.1.2
AccessToken
digitally signed document that asserts that the subject is entitled to access a Resource
Note 1 to entry: The document includes the name of the subject and the Resource being accessed.
3.1.3
ApplicationInstance
individual installation of a program running on one computer
Note 1 to entry: There can be several ApplicationInstances of the same application running at the same time on
several computers or possibly the same computer.
3.1.4
ApplicationInstanceCertificate
Certificate of an individual ApplicationInstance that has been installed in an individual host
Note 1 to entry: Different installations of one software product would have different ApplicationInstanceCertificates.
The use of an ApplicationInstanceCertificate for uses outside of what is described in the specification could greatly
reduce the security provided by the ApplicationInstanceCertificate and should be discouraged.
Note 2 to entry: also written as ApplicationInstance Certificate
3.1.5
Asymmetric Cryptography
Cryptography method that uses a pair of keys, one that is designated the Private Key and kept
secret, the other called the Public Key that is generally made available
Note 1 to entry: 'Asymmetric Cryptography, also known as "public-key cryptography". In an Asymmetric Encryption
algorithm when an entity "A" requires Confidentiality for data sent to entity "B", then entity "A" encrypts the data with
a Public Key provided by entity "B". Only entity "B" has the matching Private Key that is needed to decrypt the data.
In an asymmetric Digital Signature algorithm when an entity "A" requires message Integrity or to provide
Authentication for data sent to entity "B", entity A uses its Private Key to sign the data. To verify the signature, entity
B uses the matching Public Key that entity A has provided. In an asymmetric key agreement algorithm, entity A and
entity B each send their own Public Key to the other entity. Then each uses their own Private Key and the other's
Public Key to compute the new key value.' according to IS Glossary.
3.1.6
Asymmetric Encryption
mechanism used by Asymmetric Cryptography for encrypting data with the Public Key of an
entity and for decrypting data with the associated Private Key
3.1.7
Asymmetric Signature
mechanism used by Asymmetric Cryptography for signing data with the Private Key of an entity
and for verifying the data's signature with the associated Public Key
3.1.8
Auditability
security objective that assures that any actions or activities in a system can be recorded
3.1.9
Auditing
tracking of actions and activities in the system, including security related activities where Audit
records can be used to review and verify system operations
3.1.10
Authentication
process that assures that the identity of an entity such as a Client, Server, Publisher or user
can be verified
3.1.11
Authorization
ability to grant access to a system resource
Note 1 to entry: Authorization of access to resources should be based on the need-to-know principle. It is important
that access is restricted in a system.
3.1.12
AuthorizationService
Server which validates a request to access a Resource returns an AccessToken that grants
access to the Resource
Note 1 to entry: The AuthorizationService is also called STS (Security Token Service) in other standards.
3.1.13
Availability
security objective that assures that the system is running normally. That is, no services have
been compromised in such a way to become unavailable or severely degraded
3.1.14
Certificate Authority
entity that can issue Certificates, also known as a CA
Note 1 to entry: The Certificate certifies the ownership of a Public Key by the named subject of the Certificate. This
allows others (relying parties) to rely upon signatures or assertions made by the Private Key that corresponds to the
Public Key that is certified. In this model of trust relationships, a CA is a trusted party that is trusted by both the
subject (owner) of the Certificate and the party relying upon the Certificate. CA s are characteristic of many Public
Key infrastructure (PKI) schemes
Note 2 to entry: A private CA system (or a private sub-CA) could be used as long as all parties trust it.
3.1.15
CertificateStore
persistent location where Certificates and Certificate revocation lists (CRLs) are stored
Note 1 to entry: It can be a disk resident file structure or on Windows platforms it can be a Windows registry location.
3.1.16
Claim
statement in an AccessToken that asserts information about the subject which the Authorization
Service knows to be true
Note 1 to entry: Claims can include username, email, and Roles granted to the subject.
3.1.17
Confidentiality
security objective that assures the protection of data from being read by unintended parties
3.1.18
Cryptography
algorithm to transform clear, meaningful information into an enciphered, unintelligible form
using an algorithm and a key
3.1.19
Cyber Security Management System
program designed by an organization to maintain the security of the entire organization's assets
to an established level of Confidentiality, Integrity, and Availability, whether they are on the
business side or the industrial automation and control systems side of the organization
3.1.20
Digital Signature
value computed with a cryptographic algorithm and appended to data in such a way that any
recipient of the data can use the signature to verify the data's origin and Integrity
3.1.21
Integrity
security objective that assures that information has not been modified or destroyed in an
unauthorized manner
Note 1 to entry: More information can be found in IS Glossary.
3.1.22
Identity Provider
Server which verifies credentials provided by a Security Principal and returns a token which can
be passed to an associated Authorization Service
3.1.23
Key Exchange Algorithm
protocol used for establishing a secure communication path between two entities in an
unsecured environment whereby both entities apply a specific algorithm to securely exchange
secret keys that are used for securing the communication between them
Note 1 to entry: A typical example of a Key Exchange Algorithm is the Handshake Protocol specified in TLS.
3.1.24
Message Signature
Digital Signature used to ensure the Integrity of Messages that are sent between two entities
Note 1 to entry: There are several ways to generate and verify Message Signatures however they can be
categorized as symmetric (see Entry 3.1.35 ) and asymmetric (see Entry 3.1.5) approaches.
3.1.25
Non-Repudiation
ability to prove the occurrence of a claimed event or action and its originating entities
Note 1 to entry: The purpose of non-repudiation is to resolve disputes about the occurrence or non-occurrence of
the event or action and involvement of entities in the event.
Note 2 to entry: This definition comes from IEC 62443-4-2 and can be different from the definition used in other
industries.
3.1.26
Nonce
random number that is used once typically by algorithms that generate security keys
3.1.27
Permission
right to execute an operation, such as a read, write or a call, on a Node
3.1.28
Private Key
secret component of a pair of cryptographic keys used for Asymmetric Cryptography
Note 1 to entry: Public Key and Private Key are always generated as a pair. If either is updated, the other will also
be updated.
3.1.29
Public Key
publicly-disclosed component of a pair of cryptographic keys used for Asymmetric Cryptography
Note 1 to entry: See IS Glossary.
Note 2 to entry: Public Key and Private Key are always generated as a pair. If either is updated the other must also
be updated.
3.1.30
Public Key Infrastructure
set of hardware, software, people, policies, and procedures needed to create, manage, store,
distribute, and revoke Certificates based on Asymmetric Cryptography
Note 1 to entry: The core PKI functions are to register users and issue their public-key Certificates, to revoke
Certificates when required, and to archive data needed to validate Certificates. Key pairs for data Confidentiality
could be generated by a Certificate authority (CA) but it is better to have the Private Key owner generate the key
pair locally, provided they have a trusted key generation capability, since it improves security because the Private
Key is never transmitted to the CA. See PKI and X.509v3 for more details on Public Key Infrastructures.
3.1.31
Resource
secured entity which an application accesses
Note 1 to entry: A Resource is usually a Server.
3.1.32
Role
function assumed by a Client when it accesses a Server
Note 1 to entry: A Role can refer to a specific job function such as operator or engineer.
3.1.33
SecurityKeyService
Server that accepts AccessTokens issued by the Authorization Service and returns security
keys that can be used to access the specified Resource
Note 1 to entry: The keys are typically used for cryptography operations such as encrypting or decrypting messages
sent on a PubSub stream.
3.1.34
Secure Channel
in OPC UA, a communication path established between an OPC UA Client and Server that have
authenticated each other using certain OPC UA services and for which security parameters
have been negotiated and applied
3.1.35
Symmetric Cryptography
branch of cryptography involving algorithms that use the same key for two different steps of the
algorithm (such as encryption and decryption, or signature creation and signature verification)
Note 1 to entry: See IS Glossary.
3.1.36
Symmetric Encryption
mechanism used by Symmetric Cryptography for encrypting and decrypting data with a
cryptographic key shared by two entities
3.1.37
SecurityGroup
Publisher(s) and Subscriber(s) that utilize a shared security context
Note 1 to entry: This context can include share keys.
3.1.38
Symmetric Signature
mechanism used by Symmetric Cryptography for signing data with a cryptographic key shared
by two entities
Note 1 to entry: The signature is then validated by generating the signature for the data again and comparing these
two signatures. If they are the same then the signature is valid, otherwise either the key or the data is different from
the two entities.
3.1.39
TrustList
list of Certificates that an OPC UA Application has been configured to trust
3.1.40
Transport Layer Security
standard protocol for creating Secure Channels over IP based networks
3.1.41
X.509 Certificate
Certificate in one of the formats defined by X.509 v1, 2, or 3
Note 1 to entry: An X.509 Certificate contains a sequence of data items and has a Digital Signature computed on
that sequence. OPC UA only uses V3.
3.2 Abbreviated terms
AES Advanced Encryption Standard
CA Certificate Authority
CRL Certificate Revocation List
CSMS Cyber Security Management System
DNS Domain Name System
DSA Digital Signature Algorithm
ECDH Elliptic Curve Diffie-Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
GDS Global Discovery Server
HMAC Hash-based Message Authentication Code
JSON JavaScript Object Notation
JWT JSON Web Token
NIST National Institute of Standard and Technology
PKI Public Key Infrastructure
RSA public key algorithm for signing or encryption, Rivest-Shamir-Adleman
SHA Secure Hash Algorithm (Multiple versions exist SHA1, SHA256,…)
SKS Security Key Server
SSL Secure Sockets Layer
TLS Transport Layer Security
TPM Trusted Platform Module
UA Unified Architecture
UACP Unified Architecture Connection Protocol
UADP Unified Architecture Datagram Protocol
URI Uniform Resource Identifier
XML Extensible Mark-up Language
3.3 Conventions for security model figures
The figures in this document do not use any special conventions. Any conventions used in a
particular figure are explained for that figure.
4 OPC UA security architecture
4.1 OPC UA security environment
OPC UA is a protocol used between components in the operation of an industrial facility at
multiple levels: from high-level enterprise management to low-level direct process control of a
device. The use of OPC UA for enterprise management involves dealings with customers and
suppliers. It can be an attractive target for industrial espionage or sabotage and can also be
exposed to threats through untargeted malware, such as worms, circulating on public networks.
Disruption of communications at the process control could result in financial losses, affect
employee and public safety or cause environmental damage.
OPC UA will be deployed in a diverse range of operational environments with varying
assumptions about threats and accessibility, and with a variety of security policies and
enforcement regimes. OPC UA, therefore, provides a flexible set of security mechanisms.
Figure 1 is a composite that shows a combination of such environments. Some OPC UA
Applications are on the same host and can be easily protected from external attack. Some OPC
UA Applications are on different hosts in the same operations network and can be protected by
the security boundary protections that separate the operations network from external
connections. Some OPC UA Applications run in relatively open environments where users and
applications can be difficult to control. Other OPC UA Applications are embedded in control
systems that have no direct electronic connection to external systems. OPC UA also supports
multiple protocols and communication technologies, that can require different levels of security
and different security infrastructure. For example, both Client - Server and Publisher -
Subscriber communication is shown in Figure 1. OPC UA also defines global services such as
Certificate management, KeyCredential management, AuthorizationService, and
GlobalDiscoveryServer (GDS) to help manage security and other global functionality.
Figure 1 – OPC UA network example
4.2 Security objectives
4.2.1 Overview
Fundamentally, information system security reduces the risk of damage from attacks. It does
this by identifying the threats to the system, identifying the system's vulnerabilities to these
threats, and providing countermeasures. The countermeasures reduce vulnerabilities directly,
counteract threats, or recover from successful attacks.
Industrial automation system security is achieved by meeting a set of objectives. These
objectives have been refined through many years of experience in providing security for
information systems in general and they remain quite constant despite the ever-changing set of
threats to systems. They are described in 5.1 and 5.2 reconciles these objectives against the
OPC UA functions. Clause 6 offers additional best practice guidelines to Client and Server
developers or those that deploy OPC UA Applications.
...