Weisungen über die Sicherheit der gemeinsamen Anwendungen (SGA) in den Bereichen AHV/IV/EO/EL/FamZLw/FamZ (Gültig ab 01.01.2015; Stand: 01.01.2026)
1 Champ d’application et définitions
1.1 Champ d’application
En vertu des articles 49e, 50b, al. 1, 59, al.1, et 63, al. 3, de la loi fédérale sur l'assurance-vieillesse et survivants (LAVS RS 831.10) ainsi que de l’article 176, al. 4, du règlement du 31 octobre 1947 sur l’assurance-vieillesse et survivants (RAVS, RS 831.101), de l’article 66 de la loi sur l’assurance-invalidité (LAI, RS 831.20) et de la décision du Conseil fédéral du 4 juin 2010 (authentification à deux facteurs), les présentes directives règlent les conditionscadres pour la sécurité des applications communes dans les domaines de l’AVS/AI/APG/PC/AFA/AF.
Les applications communes sont à disposition de l’ensemble des organes d’exécution. La liste des applications communes (p.ex. ALPS) se trouve à l’annexe 1.
Ces directives ne s’appliquent pas aux collaboratrices et collaborateurs de l’administration fédérale qui disposent déjà d’un autre moyen d’authentification à deux facteurs.
Les dispositions du chapitre V s’appliquent aux applications qui utilisent AGOV.
1.2 Définitions
Authentification à deux facteurs pour les personnes : se compose, d’une part, d’un accès au moyen d’un support physique -ce que l’on détient- permettant d’accéder au réseau de la Confédération et, d’autre part, d’un nom d’utilisateur et d’un mot de passe -ce que l’on connaîtpermettant d’accéder à une application.
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
1201.1 En revanche, avec AGOV, des applications spécifiques2 sur le smartphone ou la clé de sécurité (communément appelée « clé FIDO ») remplacent le nom d’utilisateur et le mot de passe usuels, y compris l’authentification à deux facteurs.
Authentification machine : réalisée par certificats pour machines ainsi que par composants, permettant d’augmenter la sécurité des accès aux données. Pour l’authentification machine un certificat sedex est nécessaire.
Moyen d’authentification3 : support physique remis à un(-e) utilisateur(-trice), permettant d’effectuer une authentification à deux facteurs. Le ChF TNI définit le moyen d’authentification autorisé en fonction de la classification du degré de confidentialité des données d’applications.
Moyen d’identification : document d’identité délivré par l’autorité compétente, permettant d’identifier une personne. Le ChF TNI définit les moyens d’identification autorisés.
Organe d’exécution (OE) : organe d’exécution des assurances AVS, AI, APG, PC, AFA et AF.
Personne de confiance : rôle d’une collaboratrice ou d’un collaborateur de l’organe d’exécution. Elle est le point de contact des utilisateurs(-trices) d’un organe d’exécution et transmet les demandes (accès, mutations, etc.) au centre de gestion centralisée des accès de la CdC (GECA).
Registration Information Officer (RIO) : rôle d’une collaboratrice ou d’un collaborateur de l’organe d’exécution. Il ou elle est chargé(-e) de la gestion des moyens d’authentification à deux facteurs, i.e. de la commande de moyens d’authentification auprès de
L’application swiyu avec l’e-ID suisse et/ou l’application AGOV access
Le terme « moyen d’authentification » utilisé dans ce document se réfère toujours à une clé
VASCO (appareil qui transmet des codes uniques à durée de validité limitée) EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
l’organe central des moyens d’authentification et pour l’attribution, resp. révocation d’un moyen d’authentification à un(-e) utilisateur(-trice). Le rôle RIO n’est plus nécessaire pour les applications qui sont passées à AGOV.
Responsable d’application commune (RAC): gère les demandes d’accès et mutations à l’application commune dont il est en charge.
Organe central des moyens d’authentification (OCMA) : gère les demandes d’autorisations et les attributions des RIO. Il organise le support centralisé. Dès que toutes les applications sont passées à AGOV, l’OCMA n’est plus nécessaire.
Instance de coordination et d’autorisation (ICA) : résout, resp. règle les exceptions, les ambiguïtés et les cas non définis dans ces directives.
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
Centre de gestion centralisée des accès de la CdC (GECA) : gère une liste de personnes de confiance, assume le rôle de RAC pour les applications communes de la CdC et organise le support central d’AGOV.
Administrateur ALPS : gère l’attribution des accès ALPS, l’organisation de la gestion des accès et est l’interlocuteur des utilisateurs pour l’application ALPS.
Plateforme de gestion des moyens d'authentification : Plateforme de gestion, avec laquelle les RIO peuvent attribuer ou bloquer les moyens d'authentification à un utilisateur ou à une utilisatrice ou supprimer leur attribution en cas de départ ou de changement de rôle.
Authenticité : preuve d’identité
Authentification : contrôle de l’identité par un système informatique.
Autorisation : attribution de droits sur la base d’une identité vérifiée.
Fast Identity Online (FIDO) : protocole proposant une alternative sécurisée et conviviale au login traditionnel, avec nom d’utilisateur et mot de passe.
Passkeys : données de connexion cryptographiques FIDO qui sont liées au compte d’un utilisateur sur un site web ou dans une application. Les noms d’utilisateurs et les mots de passe deviennent inutiles. En lieu et place, l’utilisateur approuve la connexion en utilisant la même procédure que pour déverrouiller son appareil (par ex. données biométriques, PIN, dispositif de verrouillage).
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
Chapitre II
2. Accès individuels
2.1 Principe
2.1.1 Utilisateurs(-trices)
La liste des applications communes (voir annexe 1) renseigne sur les applications qui nécessitent une authentification à deux facteurs et sur celles qui n’en nécessitent pas (p.ex. ALPS).
Pour les applications nécessitant une authentification à deux facteurs, les utilisateurs(-trices) font une demande auprès de leur personne de confiance pour accéder aux différentes applications communes. Ils reçoivent un nom d’utilisateur(-trice) et un mot de passe ou un lien d’invitation transmis par la personne de confiance pour l’accès individuel aux applications communes.
Après avoir été identifiés par le RIO, les utilisateurs(-trices) reçoivent leur moyen d’authentification.
2.1.2 Personne de confiance
Chaque organe d’exécution (OE) désigne au moins deux et au maximum dix personnes de confiance, conformément à l’autonomie garantie par l’article 59 al.1 LAVS. Une permanence pendant les heures usuelles de travail doit être assurée.
Chaque personne de confiance doit être sous contrat d’un organe d’exécution. La personne de confiance est désignée par la direction de l’OE. Les deux parties signent le formulaire et le transmettent au GECA.
Tout changement concernant une personne de confiance doit être communiqué au GECA.
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
2.1.3 Registration Identification Officer (RIO)
Chaque organe d’exécution désigne au moins deux et au maximum dix Registration Identification Officers (RIO) conformément à l’autonomie garantie par l’article 59 al.1 LAVS. Une permanence pendant les heures usuelles de travail doit être assurée.
Lorsque la responsabilité de plusieurs organes d’exécution (OE) est portée par une même direction, celle-ci peut nommer des RIO avec une responsabilité portant sur l’ensemble de ses entités. Le groupe d’entités doit être annoncé à l’ICA au moyen du formulaire "Demande à l’ICA" [4].
Chaque RIO doit être sous contrat d’un organe d’exécution (OE). Le RIO est un (-e) utilisateur (-trice) identifié (-e) et désigné (-e) par la direction de l’OE. Les deux parties signent le formulaire "Annonce de Registration Identification Officer (RIO)" [2] et le transmettent à l’OCMA.
L’organe d’exécution peut étendre la responsabilité de son RIO à une entité tierce (p.ex. fournisseur). L’extension de la responsabilité doit être demandée à l’ICA au moyen du formulaire "Demande à l’ICA" [4].
Toute demande concernant une désignation, mutation ou révocation du rôle de RIO doit être communiquée à l’OCMA au moyen du formulaire "Annonce de Registration Identification Officer (RIO)" [2].
2.1.4 Administrateur ALPS
Chaque caisse de compensation AVS désigne au moins deux et au maximum dix Administrateurs ALPS conformément à l’autonomie garantie par l’article 59 al.1 LAVS.
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
L’attribution du rôle administrateur ALPS est demandée pour la première fois par la personne de confiance (cm 2102).
Chaque administrateur ALPS ainsi qu’une personne de confiance signent les conditions générales d’utilisation intégrées dans le formulaire [5]. Les deux parties signent le formulaire [5] et le transmettent au GECA.
2.1.5 Occupation des rôles
Les rôles de personne de confiance, d’administrateur ALPS et de RIO peuvent être assignés à une même collaboratrice ou à un même collaborateur.
2.2 Règles d’identification
Le RIO identifie les utilisateurs(-trices) de son organe d’exécution ou d’une entité tierce (cm 2124) sur la base d’un document d’identité officiel (passeport ou carte d’identité) non expiré lors de l’identification, assorti d’une photo. Il conserve une photocopie ou un enregistrement électronique du document d’identification. Celui-ci contient le prénom, le nom, la photo et la date de naissance de l’utilisateur(-trice), ainsi que le numéro et la date d’expiration du document d’identité. La photocopie ou l’enregistrement électronique est conservé jusqu’à la destruction du dossier personnel.
Si un(-e) utilisateur(-trice) ne possède pas de document d’identité officiel valable, il s’agit d’un cas particulier qui fait l’objet d’une procédure d’exception à valider par l’ICA.
Lors de chaque réception d’un moyen d’authentification, le RIO doit identifier l’utilisateur(-trice).
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
2.3 Tâches et obligations
2.3.1 Tâches et obligations des utilisateurs(-trices)
Les tâches et obligations suivantes se réfèrent aux applications communes nécessitant une authentification à deux facteurs.
Les utilisateurs(-trices) activent le moyen d‘authentification personnel avec un lien reçu par email.
Le nom d’utilisateur(-trice), le mot de passe et le moyen d’authentification sont personnels et confidentiels.
2.3.2 Tâches et obligations de la personne de
confiance
La personne de confiance est seule habilitée à déposer une demande d’accès auprès du GECA. Elle spécifie les droits d’accès des utilisateurs(-trices) aux applications communes et informe le RIO de l’attribution de droits d’accès lorsque l’authentification à deux facteurs est requise.
Les demandes d’accès sont à effectuer au moyen des formulaires mis à disposition par la GECA.
En cas de nouvelle attribution, de départ de l’utilisateur(- trice) ou en cas de changement de rôle, la personne de confiance doit annoncer la mutation au GECA et la communiquer au RIO dans les 15 jours lorsque l’authentification à deux facteurs est requise ou si l’attribution du moyen d’authentification doit être supprimée.
2.3.3 Tâches et obligations du RIO
Le RIO est responsable de l’identification des utilisateurs(- trices) auxquels il remet un moyen d’authentification. Pour cela, il applique les règles d’identification (cm 2201-2203). EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
Il enregistre le numéro de la pièce d’identité ainsi que son type dans l’application de gestion des moyens d’authentification.
Il gère une liste (au niveau des utilisateurs(-trices)) des moyens d’authentification attribués, inactifs (non-attribués), desactivés, défectueux et perdus.
Il attribue les moyens d’authentification aux utilisateurs(- trices).
Il récupère les moyens d’authentification qui ne sont plus attribués à un(-e) utilisateur(-trice) (départ ou changement de rôle), supprime sur la plateforme de gestion des moyens d’authentification l’attribution du moyen d’authentification à l’utilisateur ou l’utilisatrice et informe la personne de confiance de cette restitution. Les moyens d’authentification dont l’attribution à un utilisateur ou à une utilisatrice a été supprimé, peuvent à nouveau être attribués dans le cadre d’une authentification à doublefacteur à d’autres utilisateurs.
Il signale toute perte ou toute défectuosité d’un moyen d’authentification à l’OCMA au moyen du formulaire "Moyens d’authentification" [3].
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
Il veille à une destruction écologique (point de collecte des piles) des moyens d’authentification défectueux dans les
jours.
Les autres cas et exceptions sont réglés par l’ICA.
Le RIO commande des moyens d’authentification auprès de l’OCMA au moyen du formulaire "Moyens d’authentification" [4].
Le RIO confirme à l’OCMA la réception des moyens d’authentification au moyen du formulaire "Moyens d’authentification" [3].
2.3.4 Tâches et obligations de l’administrateur ALPS
L’administrateur ALPS gère les comptes utilisateurs ALPS, les ouvre, les clôture et les modifie lorsque cela est nécessaire. Il informe la personne de confiance de tout changement concernant les comptes utilisateurs.
L’administrateur ALPS informe les utilisateurs de l’application ALPS dont il est responsable des conditions générales d’utilisation à respecter et qu’il a lui-même acceptées et signées (cm 2133).
3. Authentification machine
3.1 Principe
Les accès machines aux applications communes ne nécessitent pas d’authentification à deux facteurs.
Les accès aux applications communes peuvent se faire soit par le réseau Internet soit par le réseau AVS/AI (en respect des directives sur le raccordement au réseau (DRR)).
Pour l’authentification machine (services WEB), le certificat sedex est utilisé. EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
Chapitre III
4. Organe centraux
4.1 Responsable d’application commune (RAC)
4.1.1 Principe
Chaque RAC est l’organe de contact entre une application commune particulière et les personnes de confiance.
Il est l’interlocuteur des personnes de confiance.
Pour chaque application commune selon la liste en annexe 1, un RAC doit être défini par l’organe responsable et annoncé à l’ICA.
Chaque RAC met à disposition les formulaires nécessaires. Toute modification de structure de formulaire doit être soumise à la validation de l’ICA.
4.1.2 Tâches et obligations
Le RAC gère les droits d’accès d’utilisateurs (-trices) à une application commune particulière. La demande est déposée par la personne de confiance.
Le RAC met en place une organisation de support, à valider par l’ICA.
Le RAC contrôle au moins tous les six mois les accès de tous les utilisateurs de l’application commune dont il est responsable. Les accès utilisateurs inactifs depuis plus de
mois seront effacés par la GECA sur demande de la personne de confiance.
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
4.2 Organe central des moyens d’authentification
(OCMA)
4.2.1 Principe
L’organe central des moyens d’authentification assume la fonction d’organe de coordination entre le fournisseur de moyens d’authentification et les RIO.
Le rôle de l’OCMA est exercé par la CdC
4.2.2 Tâches
L’OCMA valide les RIO en les activant et les désactivant dans l’application de gestion des moyens d’authentification dans un délai d’un jour ouvrable après réception de la demande.
Il s’assure que les moyens d’authentification commandés sont remis aux organes d’exécution (OE).
Il gère un inventaire des moyens d’authentification remis au niveau des OE et des groupes d’entités.
Il met en place une organisation de support, à valider par l’ICA.
L’OCMA vérifie tous les 6 mois si un moyen d'authentification est toujours attribué aux noms d'utilisateur supprimés. Si tel est le cas, l’OCMA demande au RIO responsable de supprimer l'attribution du moyen d'authentification conformément au Cm. 2325. L’OCMA est autorisé à supprimer les attributions des moyens d'authentification à des noms d'utilisateur supprimés.
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
4.3 Instance de coordination et d’autorisation (ICA)
4.3.1 Principe
Le rôle d’instance de coordination et d’autorisation (ICA) est exercé par l’OFAS (egov@bsv.admin.ch).
Elle peut déléguer ses tâches.
4.3.2 Tâches
Elle valide les demandes des RAC, de GECA, de l’OCMA et des organes d’exécution conformément à ces directives.
Sur demande, elle règle les cas particuliers.
L’ICA contrôle au moins auprès des organes d’exécution (OE) :
Le nombre de RIO
La liste des utilisateurs (-trices) autorisés
Les copies des pièces d’identité des utilisateurs (-trices) autorisés
La liste des moyens d’authentification activés et inactivés
L’ICA contrôle au moins auprès de GECA:
La liste des personnes de confiance
La gestion des mutations des personnes de confiances
L’ICA contrôle au moins auprès de l’organe central des moyens d’authentification (OCMA) :
La liste des RIO
La gestion des mutations des RIO
L‘inventaire des commandes des moyens d’authentification
L’ICA peut définir d’autres aspects à contrôler.
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
4.4 Centre de gestion centralisée des accès (GECA)
4.4.1 Principe
En plus de ses tâches de RAC pour les applications communes de la CdC et le support d’AGOV, la GECA gère la liste des personnes de confiance des organes d’exécution pour toutes les applications communes de la liste en annexe 1.
Le rôle de GECA est exercé par la CdC (accesscenter@zas.admin.ch).
4.4.2 Tâches
La GECA gère la liste des personnes de confiance des organes d’exécution.
La GECA reçoit toutes les demandes d’accès aux applications communes de la liste en annexe 1.
La GECA vérifie que la demande d’accès a bien été déposée par une personne de confiance.
La GECA transmet ensuite les demandes d’accès, lorsque l’application commune n’est pas de sa compétence, aux RAC compétents.
La GECA organise le support central d’AGOV.
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
Chapitre V (AGOV)
5. Accès personnel
5.1 Principe
Les utilisateurs demandent l’accès à une application commune en s’adressant à une personne de confiance.
Lors de l’accès à une application qui requiert au minimum AGOVaq3004, une vérification (payante) par vidéo doit être réalisée.
Les coûts de la vérification par vidéo doivent être payés avec un moyen de paiement en ligne courant avant le début de la vérification. L’organisation du paiement et ses modalités incombent à l’organe d’exécution (OE).
Si aucun smartphone n’est utilisé, l’utilisateur reçoit une clé FIDO sans formalités particulières de l’OE.
Les OE se procurent eux-mêmes les clés FIDO selon les dispositions d’acquisition (chap. 5.3.3).
5.2 Règles d’identification par vidéo
La vérification d’identité de l’utilisateur est réalisé par vidéo. À cet effet, AGOV met à disposition la solution « IDnow »5.
Les conditions d’une identification par vidéo sont les suivantes : • Elle est possible pour les personnes domiciliées en Suisse ou à l’étranger.
Niveau de protection de l’administration fédérale : https://www.eiam.swiss/?c=eiam!qoa&l=fr
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
• Elle est valable cinq ans.
• Les documents suivants peuvent devoir être présentés lors de la vérification d’identité par vidéo :
o cartes d’identité et passeports, selon la liste des pays ;
o ne sont pas acceptés : permis de séjour suisses ;
o ne sont pas non plus acceptés : d’autres documents tels que le permis de conduire, le SwissPass, la carte d’étudiant, etc. ;
o le titulaire de compte AGOV doit procéder en personne à la vérification par vidéo. Aucune autre personne ne peut le remplacer lors de cette procédure.
Si un utilisateur ne dispose pas d’un document d’identité officiel valable, la vérification par vidéo ne peut être réalisée et l’accès à l’application correspondante n’est pas possible. Une procédure d’exception, telle que celle décrite au ch. 2202, n’existe pas dans le cas d’AGOV.
5.3 Tâches et obligations
5.3.1 Tâches et obligations des utilisateurs
Un login AGOV est personnel. Il est interdit de le transmettre à une ou plusieurs autres personnes.
Les comptes AGOV sont individuels et représentent une unique personne physique, indépendamment du fait qu’elle agisse pour son propre compte via le login AGOV ou pour le compte, par exemple, d’une personne morale. La responsabilité de la bonne utilisation du login AGOV, des applications liées et des transactions qui y sont effectuées incombe à la personne physique. Autrement dit, cette personne est également tenue de conserver les facteurs de login correspondants (application AGOV access ou clé
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
de sécurité) en toute sécurité et de les utiliser de manière appropriée.
5.3.2 Tâches de l’organe d’exécution
Les coûts payés par l’OE pour une vérification par vidéo ou une clé FIDO peuvent être comptabilisés sous les comptes d’administration suivants de chacun des fonds concernés :
Caisses de compensation AVS selon les DCMF :
212.3291 Coûts d’acquisition des clés FIDO (login officiel
des autorités AGOV)
212.3292 Coûts liés à l’identification vidéo (login officiel
des autorités AGOV)
Offices AI selon la CCAOAI :
380.5391 Coûts d’acquisition des clés FIDO (login officiel
des autorités AGOV)
380.5392 Coûts liés à l’identification vidéo (login officiel
des autorités AGOV)
Dans le cas des caisses d’allocations familiales indépendantes, les coûts liés à la mise en œuvre de la vérification par vidéo et à l’acquisition des clés FIDO sont à la charge de la caisse d’allocations familiales concernée.
5.3.3 Dispositions d’acquisition
Les dispositions d’acquisition ne concernent que les clés FIDO dont les frais d’acquisition sont remboursés par les fonds de compensation ou le GECA.
Le prix d’acquisition d’une clé FIDO s’élève à 30 francs au plus (TVA incluse, hors frais d’envoi). L’ICA peut accorder une autorisation exceptionnelle pour l’acquisition de clés FIDO plus coûteuses.
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
Les clés FIDO doivent être remises uniquement aux utilisateurs d’un OE ayant besoin d’un accès à une application AGOV. Toute remise d’une clé FIDO à une personne privée ou qui n’utilise pas AGOV est interdite.
L’acquisition et la conservation (réserve) sont limitées à
% de l’effectif d’un OE.
Le remboursement des frais d’acquisition est contrôlé par l’OFAS. Chaque OE doit pouvoir prouver en tout temps ses frais d’acquisition.
6. Entrée en vigueur
Les présentes directives entrent en vigueur au 1er janvier 2017.
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de
Annexe 1
Type Nom
Application CdC ACOR
Application CdC Escal
Application CdC RaFAM
Application CdC RPC
Application CdC Sumex
Application CdC SWAP
Application CdC NRA
Application CdC NRR
Application CdC GAIME
Application CdC JiveX
Application CdC TEDAI
Application OFAS ALPS
Application OFAS eRegress
Application OFAS ESP
EDI BSV | Directives sur la sécurité des applications communes (SAC) dans les domaines de