BACnet/SC (BACnet Secure Connect) : ce que ça sécurise vraiment dans une GTB moderne, et ce que ça ne remplace pas

16/04/2026
by Domocasa
Guides techniques Réseaux et Wi-Fi Smart Building et GTB

Illustration générée par IA — visuel conceptuel.

BACnet est omniprésent dans les architectures de GTB/BMS. Pourtant, dès qu’on veut traiter la cybersécurité et l’intégration OT/IT « proprement » (réduction d’exposition, filtrage réseau réaliste, gouvernance des accès), les architectures BACnet/IP « classiques » peuvent devenir difficiles à maîtriser : flux qui s’étendent au-delà du strict nécessaire, comportements réseau plus complexes à cadrer, et absence d’un canal chiffré/authentifié standard « sur le fil ».

BACnet/SC (BACnet Secure Connect) répond à une partie de ce problème : ce n’est pas « un nouveau BACnet », mais une option de couche data link standardisée pour transporter des messages BACnet au-dessus de connexions WebSocket sécurisées (WSS) avec TLS. La référence normative d’origine est ANSI/ASHRAE Addendum bj to ANSI/ASHRAE Standard 135-2016 (PDF). (Miroir : bacnet.org (PDF))

Cette évolution a des impacts d’architecture très réels (hub, certificats, dépendances réseau), et elle ne remplace pas le reste de votre démarche cybersécurité.

Si vous souhaitez replacer BACnet/SC dans une vision plus large « bâtiment tertiaire » (couches, responsabilités, interfaces), vous pouvez aussi lire : Qu’est-ce que l’immotique ? Définition, usages, bénéfices et mise en œuvre.

Références (textes utiles)

À retenir (sans marketing)

  • BACnet/SC vise la sécurité du transport : l’addendum indique que seules des connexions WebSocket sécurisées via TLS sont utilisées, et que le support de TLS v1.3 est requis (dans le sens : TLS 1.3 doit être supporté/accepté par les ports BACnet/SC).
  • L’architecture change : le texte est explicite sur le fait qu’un hub est requis pour un réseau BACnet/SC ; un hub de secours (failover) est une option de disponibilité, à décider et configurer au niveau « site ».
  • L’authentification mutuelle TLS (souvent décrite pédagogiquement comme une logique « mTLS ») repose sur des certificats opérationnels et un magasin de CA. Cela « outille » très bien le projet, mais ne remplace pas la gouvernance PKI du site.
  • BACnet/SC ne remplace pas la segmentation OT/IT, le durcissement système, la gestion des comptes, ni une stratégie d’accès distant maîtrisée.

BACnet/SC : définition simple (ce que c’est, au sens du standard)

BACnet/SC est défini dans l’addendum ANSI/ASHRAE Addendum 135-2016 bj. Il introduit une option de couche data link (« BACnet Secure Connect ») qui fait transiter des échanges BACnet via des connexions WebSocket sécurisées (cf. RFC 6455) avec TLS (cf. TLS 1.3 — RFC 8446).

Le texte indique notamment :

  • que seules des connexions WebSocket sécurisées (TLS) sont utilisées pour BACnet/SC ;
  • que le support de TLS v1.3 est requis ;
  • que l’architecture BACnet/SC s’organise autour d’un hub, avec la possibilité d’un hub failover (secours) selon la stratégie du site.

Ce que BACnet/SC sécurise vraiment (et ce que cela change)

Chiffrement, intégrité, authentification : la sécurité « sur le fil »

L’intérêt le plus clair de BACnet/SC est de reposer sur un transport moderne : WebSockets + TLS. L’addendum relie explicitement l’usage de connexions WebSocket sécurisées et de TLS (dont TLS 1.3) à la confidentialité, l’intégrité et l’authenticité des messages BVLC transmis sur la connexion.

Autre point important : l’addendum indique que, pour établir une connexion WebSocket sécurisée, une authentification mutuelle TLS doit être réalisée. Pédagogiquement, on peut rapprocher cela d’une logique « mTLS » au sens suivant : certificat côté pair initiateur et côté pair acceptant.

Point de prudence (à lire comme un cadrage projet) : le standard décrit les mécanismes minimaux (certificats, CA de confiance, validations). En revanche, la « force » de l’identité (qui signe, comment l’émission est contrôlée, quelles règles de nommage/attributs, révocation, etc.) dépend de la PKI et de la politique du site, ainsi que des capacités concrètes des produits. Il faut donc le traiter comme un sujet de gouvernance IT/OT et de recette, pas comme un « effet automatique » du protocole.

Un modèle « hub-and-spoke » : le hub devient un composant critique

BACnet/SC introduit une topologie logique où des nœuds établissent des connexions vers une fonction hub. Le hub devient un point central d’exploitation (supervision, disponibilité, mise à jour, durcissement, gestion des certificats) : il faut donc le traiter comme un composant OT sensible, au même titre qu’un superviseur GTB ou qu’une passerelle critique.

Hub primaire requis, hub failover possible (option de disponibilité)

L’addendum indique que, pour chaque réseau BACnet/SC, une fonction hub est requise (hub primaire). Il prévoit aussi qu’un hub failover (secours) peut être présent pour améliorer la disponibilité : c’est une décision « site », qui doit être configurée en conséquence dans les nœuds.

Le point clé n’est pas seulement d’avoir « deux serveurs », mais de définir un scénario d’exploitation : bascule, tests de reprise, responsabilités (IT/OT), et dépendances réseau.

Connexions directes entre nœuds : option utile… mais à cadrer

Le texte décrit aussi la possibilité de connexions directes entre nœuds, en complément du hub. Il précise en particulier que les connexions directes ne concernent que des nœuds d’un même réseau BACnet/SC, et qu’un nœud utilisant des connexions directes doit rester connecté au hub.

Sur le plan cybersécurité et réseau, cela peut augmenter le nombre de flux est/ouest (east-west) à autoriser et surveiller. La bonne approche consiste donc à :

  • le décider explicitement (ce n’est pas un détail),
  • l’intégrer au modèle de flux et aux règles firewall,
  • le recetter (latence, reprise après coupure, supervision).

Ce que BACnet/SC ne remplace pas (et pourquoi il faut le dire clairement)

BACnet/SC ne durcit pas les équipements

Chiffrer le transport ne suffit pas à sécuriser une GTB. Le risque « OT » vient aussi des systèmes eux-mêmes : comptes et mots de passe, services exposés, mises à jour, dépendances applicatives, supervision, gestion de sauvegardes, etc. BACnet/SC aide à protéger les échanges réseau, mais ne remplace pas l’hygiène d’exploitation.

BACnet/SC ne remplace pas la segmentation OT/IT

Une architecture OT raisonnable doit rester segmentée et filtrée : qui parle à qui, pourquoi, et par quel chemin. Ce principe s’applique même avec un protocole chiffré, et il devient encore plus important dès que des systèmes convergent (réseau, Wi‑Fi, cybersécurité, supervision, CCTV, contrôle d’accès, etc.).

Sur ce sujet, deux lectures complémentaires Domocasa peuvent aider à structurer un projet :

BACnet/SC ne vous évite pas la gouvernance des certificats (PKI) : c’est même l’inverse

BACnet/SC impose que les pairs soient configurés avec des éléments de confiance (au minimum : un magasin de CA, un certificat opérationnel unique et sa clé privée), afin de permettre l’authentification mutuelle entre pairs.

En revanche, le “comment” (qui détient la CA, comment les certificats sont émis, renouvelés, révoqués, audités, archivés) est un sujet site-specific : l’addendum indique explicitement que le choix d’une ou plusieurs CA et leur contrôle relèvent de la politique du site.

Note de cadrage : les questions de PKI et de responsabilités (IT/OT, exploitation, prestataires) relèvent du cadrage projet et contractuel. Cet article fournit des repères d’architecture et d’exploitation, sans se substituer à une analyse juridique ou à vos clauses contractuelles.

Impacts d’architecture : où placer le hub, et comment éviter une exposition inutile

Principe : rester « local-first », et contrôler l’accès distant

Dans une stratégie OT cohérente, l’objectif est que le bâtiment reste exploitable localement (GTB, automates, supervision), et que l’accès distant (si nécessaire) soit traité comme un service contrôlé : VPN/bastion, traçabilité, durée d’accès, comptes nominaux, et suppression des accès devenus inutiles.

Si votre contexte est hôtelier ou multi-prestataires (réseau, GTB, GRMS, vidéosurveillance, contrôle d’accès, etc.), cet article fournit un cadre de réflexion utile : Cybersécurité d’un hôtel connecté : comment protéger GRMS, PMS, GTB et réseau ?

Pattern d’intégration (à adapter) : hub dans une zone OT/DMZ, flux sortants depuis les nœuds

Sans imposer une architecture unique, un pattern courant consiste à :

  • placer le hub BACnet/SC dans une zone OT (ou une zone tampon/DMZ OT selon le projet) ;
  • autoriser les nœuds BACnet/SC à initier des connexions wss vers le hub (flux explicitement ouverts et filtrés) ;
  • éviter toute exposition directe du hub vers Internet ;
  • documenter les dépendances d’infrastructure (DNS, temps/NTP, supervision, sauvegardes).

Point à retenir : l’addendum impose l’usage d’URI en wss pour établir une connexion hub, et précise qu’un schéma autre que wss n’est pas supporté pour cette fonction. Concrètement, l’infrastructure réseau « invisible » (résolution de noms, disponibilité, segmentation, règles) devient partie intégrante de la fiabilité.

Mini-checklist projet (MOA / BET / IT / intégrateur GTB)

  • Produits : quels équipements supportent réellement BACnet/SC (et avec quelles limites) ? Ne pas supposer : vérifier sur documentations fabricant.
  • Hubs : où sont hébergés hub primaire et hub failover (si prévu) ? Qui administre ? Comment teste-t-on la bascule ?
  • PKI : qui contrôle la CA du site ? Quel processus de signature, renouvellement, révocation, et quelles preuves d’audit ?
  • Réseau : segmentation OT/IT, flux strictement nécessaires, et décision explicite sur l’activation (ou non) des connexions directes entre nœuds.
  • Exploitation : sauvegardes, supervision, procédures de remplacement/retrait d’équipements (et traitement des certificats/clé privée en fin de vie).

Conclusion : BACnet/SC est un levier, pas une stratégie complète

BACnet/SC est une évolution majeure : il apporte un transport chiffré et authentifié via WebSockets sécurisés (TLS), et il formalise une architecture avec hub (et, en option, des connexions directes). Mais ce gain s’accompagne d’un déplacement de responsabilités : PKI/certificats, exploitation du hub, et architecture réseau OT/IT deviennent des sujets centraux.

En pratique, le bon résultat vient d’une approche « bâtiment » : clarifier les responsabilités (IT/OT), segmenter, documenter, recetter les modes dégradés, puis sélectionner des produits réellement compatibles et maintenables.

Vous travaillez sur un projet tertiaire (bureaux, retail, hôtellerie) et souhaitez cadrer une architecture GTB/BMS compatible BACnet/SC sans exposition inutile ? Nous pouvons vous aider à transformer l’intention cybersécurité en choix d’architecture et de recette.

Copyright © 2025 Domocasa. All rights reserved.